CN117114903A

CN117114903A - Data processing method, device, equipment and storage medium

Info

Publication number: CN117114903A
Application number: CN202210510165.8A
Authority: CN
Inventors: 秦波; 蓝虎
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2022-05-11
Filing date: 2022-05-11
Publication date: 2023-11-24

Abstract

The embodiment of the application discloses a data processing method, a device, equipment and a storage medium, wherein the method comprises the following steps: when a first node in the blockchain network acquires a service billing request of a service object, sending billing transaction to a second node so that the second node generates billing result notification based on the object risk state of the service object; the object risk state is stored in a blockchain ledger of a blockchain network; if the billing result notification is a billing success notification, forwarding transaction data associated with the billing success notification to the tax office management terminal based on the management contract deployed on the first node; the tax office management terminal is used for sending a state change request to the second node when determining that the object risk state is the second risk state; the state change request is used for instructing the second node to change the object risk state from the first risk state to the second risk state. By adopting the embodiment of the application, the real-time performance of risk management and control can be improved.

Description

Data processing method, device, equipment and storage medium

Technical Field

The present application relates to the field of blockchain technologies, and in particular, to a data processing method, apparatus, device, and storage medium.

Background

The blockchain electronic bill has no limit of invoice quantity acquisition and limit of invoicing amount, and has a virtual risk, so tax authorities need to control the risk of invoicing requirements of business objects (e.g. enterprise objects). Currently, a blockchain node (e.g., billing agency) running a bill data synchronization program may poll the blockdata on the chain according to a timed task (e.g., every one hour), so as to count the total amount of billing of each enterprise object, so as to determine whether the enterprise object belongs to an inauguration enterprise. For example, if an billing agent detects that an enterprise risk status of an enterprise object (e.g., enterprise object a) is a risk-free status at a certain detection timestamp (e.g., ten am) and the next detection timestamp of the billing agent is eleven am, this means that if the enterprise object a changes the risk status between ten am and eleven am, the billing agent still executes the billing service for the enterprise object a, resulting in immeasurable loss, that is, there will be a delay associated with the statistical period of the timing task in determining the enterprise risk status, which will reduce the real-time performance of risk management.

Disclosure of Invention

The embodiment of the application provides a data processing method, a device, equipment and a storage medium, which can improve the real-time performance of risk management and control.

An aspect of an embodiment of the present application provides a data processing method, which is performed by a first node in a blockchain network, including:

when a business billing request of a business object is acquired, sending a billing transaction corresponding to the business billing request to a second node in the blockchain network, so that the second node generates a billing result notice for returning to the first node based on the object risk state of the business object; the object risk state is stored in a blockchain ledger of a blockchain network;

if the billing result notification is a billing success notification, triggering a management contract deployed on the first node, and forwarding transaction data associated with the billing success notification to a tax office management terminal based on the management contract; the invoicing success notice is generated by the second node when the object risk state is the first risk state; the tax office management terminal is used for sending a state change request to a second node when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object; the state change request is used for indicating the second node to change the object risk state from the first risk state to the second risk state; the second risk status is used to indicate a failure of the second node to issue an invoice.

An aspect of an embodiment of the present application provides a data processing method, which is performed by a second node in a blockchain network, including:

acquiring an invoicing transaction sent by a first node in a blockchain network; the billing transaction is generated by the first node based on the business billing request of the business object;

acquiring an object risk state of a business object from a blockchain account book of a blockchain network, and generating an invoicing result notice for returning to a first node based on the object risk state; the first node is used for forwarding transaction data associated with the billing success notification to the tax office management terminal based on the management contract deployed on the first node when the billing result notification is the billing success notification; the tax office management terminal is used for generating a state change request when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object;

receiving a state change request sent by a tax office management terminal, and changing the object risk state from a first risk state to a second risk state in a blockchain ledger; the second risk status is used to indicate a failure of the second node to issue an invoice.

An aspect of an embodiment of the present application provides a data processing apparatus, including:

The billing transaction sending module is used for sending the billing transaction corresponding to the business billing request to a second node in the blockchain network when the business billing request of the business object is acquired, so that the second node generates a billing result notice for returning to the first node based on the object risk state of the business object; the object risk state is stored in a blockchain ledger of a blockchain network;

the transaction data forwarding module is used for triggering the management contract deployed on the first node if the invoicing result notification is an invoicing success notification, and forwarding transaction data associated with the invoicing success notification to the tax bureau management terminal based on the management contract; the invoicing success notice is generated by the second node when the object risk state is the first risk state; the tax office management terminal is used for sending a state change request to a second node when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object; the state change request is used for indicating the second node to change the object risk state from the first risk state to the second risk state; the second risk status is used to indicate a failure of the second node to issue an invoice.

Wherein, the transaction of making an invoice send module includes:

the billing request acquisition unit is used for acquiring a business billing request of a business object; the business billing request comprises information to be signed and object signature information; the object signature information is obtained after signing the information to be signed based on an object private key of the service object; the information to be signed comprises bill information determined by the business object;

the signature verification unit is used for acquiring an object public key corresponding to the business object from the blockchain account book, and verifying the object signature information based on the object public key to obtain a signature verification result;

the parameter verification unit is used for carrying out parameter verification on the bill information in the information to be signed if the verification result indicates that verification is successful, so as to obtain a parameter verification result;

and the billing transaction sending unit is used for sending the billing transaction corresponding to the business billing request to a second node in the blockchain network if the parameter verification result indicates that the verification is successful.

Wherein, this parameter check unit includes:

the registration information acquisition subunit is used for acquiring the object registration information of the business object from the blockchain ledger if the verification result indicates that the verification is successful;

the information comparison subunit is used for comparing the object registration information with the bill information to obtain a comparison result;

And the verification success result generation subunit is used for generating a parameter verification result for indicating that the verification is successful if the comparison result indicates that the registration information of the object is consistent with the bill information.

Wherein, this parameter verification unit still includes:

the verification failure result generation subunit is used for generating a parameter verification result for indicating verification failure and generating first prompt information for indicating information modification of the business object if the comparison result indicates that the registration information of the object is inconsistent with the bill information;

and the prompt information sending subunit is used for sending the first prompt information to the object terminal corresponding to the service object so as to enable the object terminal to return the modified bill information.

Wherein, this transaction of making an invoice sending unit includes:

the billing transaction generation subunit is used for executing transaction business aiming at the business object based on the business billing request if the parameter verification result indicates that verification is successful, and generating billing transaction according to the transaction execution result of the transaction business;

the encryption processing subunit is used for acquiring a node public key of a second node in the blockchain network from the blockchain account book, and carrying out encryption processing on the open transaction based on the node public key to obtain transaction encryption data;

And the encrypted data transmitting subunit is used for transmitting the transaction encrypted data to the second node so that the second node can decrypt the transaction encrypted data based on the node private key of the second node to obtain the billing transaction.

Wherein the apparatus further comprises:

the first generation module is used for generating second prompt information for indicating the business object to adjust the data volume if the billing result notification is a billing failure notification and the billing failure notification indicates that the billing accumulated data volume of the business object in the billing statistics period reaches a data volume threshold;

the first sending module is used for sending the billing failure notification and the second prompt information to the object terminal corresponding to the business object so that the object terminal generates a data volume adjustment request based on the second prompt information;

the data volume adjustment request receiving module is used for receiving the data volume adjustment request returned by the target terminal and sending the data volume adjustment request to the tax office management terminal so that the tax office management terminal can adjust the data volume threshold of the service target.

Wherein the apparatus further comprises:

the second generation module is used for generating third prompt information for indicating the business object to conduct risk complaints if the billing result notification is billing failure notification and the billing failure notification indicates that the business object has abnormal risk;

And the second sending module is used for sending the billing failure notification and the third prompt information to the object terminal corresponding to the business object so that the object terminal carries out risk complaints based on the third prompt information.

Wherein the apparatus further comprises:

the change information acquisition module is used for acquiring state change prompt information sent by the second node; the state change prompt information is generated when the second node changes the object risk state from the first risk state to the second risk state;

the contact information acquisition module is used for acquiring an association object with an association relation with the business object from the blockchain account book and acquiring contact information of the association object;

and the change information sending module is used for sending the state change prompt information to the associated terminal corresponding to the associated object based on the contact information.

the billing transaction acquisition module is used for acquiring billing transactions sent by a first node in the blockchain network; the billing transaction is generated by the first node based on the business billing request of the business object;

the risk state acquisition module is used for acquiring the object risk state of the business object from the blockchain account book of the blockchain network and generating an invoicing result notice for returning to the first node based on the object risk state; the first node is used for forwarding transaction data associated with the billing success notification to the tax office management terminal based on the management contract deployed on the first node when the billing result notification is the billing success notification; the tax office management terminal is used for generating a state change request when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object;

The risk state changing module is used for receiving a state changing request sent by the tax office management terminal and changing the risk state of the object from a first risk state to a second risk state in the blockchain ledger; the second risk status is used to indicate a failure of the second node to issue an invoice.

Wherein the blockchain ledger comprises an information registration block;

the apparatus further comprises:

the registration request acquisition module is used for acquiring an object information registration request sent by the tax office management terminal; the object information registration request carries the object registration information of the business object;

the registration information packaging module is used for packaging the object registration information to obtain a block to be verified of the block chain account book to be written;

the block broadcasting module is used for broadcasting the block to be verified to a third node in the block chain network so that the third node can carry out consensus on the acquired block to be verified to obtain a consensus result for returning to the second node;

and the information registration block writing module is used for determining that the block chain nodes in the block chain network reach the consensus if the consensus result exceeding the consensus threshold value indicates that the consensus is successful in the consensus result, and writing the block to be verified into the block chain account book as the information registration block.

The risk state acquisition module comprises:

the risk state acquisition unit is used for calling the bill contract deployed on the second node and acquiring the object risk state of the business object from the blockchain ledger of the blockchain network based on the bill contract;

the success notification generation unit is used for generating a success notification of the invoicing when the invoicing transaction is successfully written into the blockchain ledger if the risk state of the object is the first risk state;

the failure notification generation unit is used for generating an invoicing failure notification if the object risk state is a second risk state;

and a result notification determination unit configured to notify the billing success notification or the billing failure notification as a billing result notification for returning to the first node.

Wherein, this risk state change module includes:

a state change request receiving unit for receiving a state change request sent by the tax administration terminal, and generating a state change transaction associated with the business object based on the state change request;

the initial tree determining unit is used for acquiring an initial block with the maximum generation timestamp from the blockchain ledger and determining an initial state tree in the initial block; the object risk state of the business object in the initial state tree is a first risk state;

The target tree determining unit is used for changing a first risk state in the initial state tree into a second risk state, determining the changed initial state tree as a target state tree and determining a state snapshot corresponding to the target state tree;

a block hash value determining unit, configured to determine a transaction hash value of the state change transaction, and determine a block hash value of the target block to be generated based on the transaction hash value;

the target block generating unit is used for carrying out packing processing on the block hash value of the initial block, the state snapshot corresponding to the target state tree and the block hash value of the target block to obtain the target block;

a target block writing unit, configured to take a target block as a next block of the initial block when a block chain node in the block chain network achieves consensus for the target block; the generation timestamp in the target block is used to update the maximum generation timestamp on the blockchain ledger.

In one aspect, an embodiment of the present application provides a computer device, including: a processor and a memory;

the processor is connected to the memory, wherein the memory is configured to store a computer program, and when the computer program is executed by the processor, the computer device is caused to execute the method provided by the embodiment of the application.

In one aspect, the present application provides a computer readable storage medium storing a computer program adapted to be loaded and executed by a processor, so that a computer device having the processor performs the method provided by the embodiment of the present application.

In one aspect, embodiments of the present application provide a computer program product comprising a computer program stored on a computer readable storage medium; the processor of the computer device reads the computer program from the computer-readable storage medium, and the processor executes the computer program, so that the computer device performs the method in the embodiment of the present application.

In the embodiment of the application, the first node in the blockchain network can receive the invoicing result notification returned by the second node in the blockchain network, when the invoicing result notification is an invoicing success notification, the transaction data associated with the invoicing success notification can be sent to the tax office management terminal in real time based on the locally deployed management contract, once the tax office management terminal detects that the object risk state of the business object needs to be changed, the state change request can be sent to the second node, so that the second node updates the object risk state of the business object to the second risk state in real time on the blockchain account book, and because the second risk state is used for indicating the invoicing failure, the second node can rapidly intercept new invoicing requirements according to the object risk state (namely the second risk state) of the business object stored in the blockchain account book when the invoicing requirements exist later.

Drawings

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

FIG. 1 is a schematic block chain node system according to an embodiment of the present application;

FIG. 2 is a schematic diagram of a scenario for data interaction according to an embodiment of the present application;

FIG. 3 is a schematic flow chart of a data processing method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a scenario in which object registration information is uplink according to an embodiment of the present application;

fig. 5 is a schematic diagram of a scenario in which information verification is performed on a service billing request according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of a data processing method according to an embodiment of the present application;

FIG. 7 is a schematic diagram of a architecture for implementing real-time pneumatic control of blockchain electronic tickets according to an embodiment of the present application;

FIG. 8 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;

FIG. 9 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a computer device according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a data processing system according to an embodiment of the present application.

Detailed Description

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

It should be appreciated that embodiments of the present application provide a blockchain-based bill real-time wind control scheme, where a blockchain (or blockchain) may be a serial literal record (also called a block) that is cryptographically concatenated and protects content, i.e., includes a series of blocks that succeed each other in chronological order of generation, and new blocks are not removed once added to the blockchain, where each block may include an encrypted hash (i.e., a parent block hash value) of a previous block, a generated timestamp, and transaction data (typically represented by a hash value calculated using the merkel tree algorithm), such a design making the content of the block difficult to tamper with. The distributed ledgers serially connected by blockchain technique enable two parties to record transactions effectively and to check the transactions permanently. Among other things, the blockchain used to store business transactions (e.g., information registration transactions, billing transactions, status change transactions, etc.) associated with business objects (e.g., business objects, personal objects, etc.) may be referred to as blockchain ledgers.

Where a smart contract is an application or program running on a blockchain node, typically a set of digitized protocols with specific rules that can be enforced. These rules are predefined by the computer source code that all network nodes will replicate and execute. The embodiment of the application can be used for deploying the consensus nodes in the blockchain network, and executing the intelligent contracts associated with the blockchain electronic bill is called bill contracts, and the intelligent contracts deployed locally at the blockchain light nodes are called management contracts.

Referring to fig. 1, fig. 1 is a schematic structural diagram of a blockchain node system according to an embodiment of the present application. As shown in fig. 1, a blockchain node system in an embodiment of the present application (e.g., blockchain node system 1X shown in fig. 1) may be a distributed system formed by a plurality of blockchain nodes connected by a network communication. The blockchain network corresponding to the blockchain system 1X is a peer-to-peer network (Peer to peer networking, abbreviated as P2P network), that is, a distributed application architecture for distributing tasks and workloads among users, and is a networking or network form formed by peer-to-peer computing models at an application layer. The blockchain node system can include, but is not limited to, a blockchain system corresponding to a blockchain, wherein the blockchain is a form of the blockchain, compared with public data disclosure of a public chain, free joining and exiting of nodes, the blockchain can be limited to participation of internal members of the alliance, read-write permission and participation accounting permission on the blockchain are formulated according to alliance rules, namely, the internal members of the alliance can have related permission to access data, the joining of the nodes to the network needs to be licensed, and the blockchain system is more suitable for supervision and faster transaction speed, and a plurality of independent account books can be established.

The blockchain system 1X shown in fig. 1 may include a plurality of blockchain nodes, where the plurality of blockchain link nodes may include a node 10A, a node 10B, a node 10C, …, and a node 10N. The blockchain node in the blockchain system 1X may be any type of computer device that accesses the blockchain network, for example, the computer device may be a terminal device that accesses the blockchain network, or may be a server that accesses the blockchain network, where the specific form of the blockchain node is not limited. It is to be appreciated that the terminal devices that access the blockchain network can include: smart terminals with data processing functions such as smart phones, tablet computers, notebook computers, desktop computers, smart speakers, smart watches, vehicle-mounted terminals, smart televisions and the like. The server accessed to the blockchain network can be an independent physical server, a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server for providing cloud computing service.

The blockchain nodes in the blockchain network shown in fig. 1 mainly have the following functions: wallet, blockchain database, network routing. Each node may have routing functionality, but not necessarily all other functions, and a common node in a general blockchain network (e.g., node 10B shown in fig. 1) may include four functions. Such consensus nodes may participate in checking, broadcasting transaction data, and block information, and may discover and maintain connections with other nodes. The consensus Node will contain a complete blockchain database, including all transaction data, and this Node containing all functions is also called Full Node. Other nodes do not need to synchronize huge amounts of block data, but rather synchronize a portion of the blockchain database, e.g., the nodes may synchronize block header data with transaction data associated with their own nodes, without synchronizing block and state data. They accomplish transaction verification by means of "simplified transaction verification (Simplified Payment Verification, SPV for short)", which nodes may be referred to as blockchain light nodes (light nodes) or SPV nodes.

For ease of understanding, embodiments of the present application may select a blockchain node (e.g., node 10A) in a blockchain network as a first node in the blockchain network that may have the authority to bill business objects of a region (e.g., district, city, province), and that may be locally deployed with a smart contract (i.e., management contract) associated with a blockchain electronic bill. The first node may be a blockchain light node in a blockchain network, or may be a full-scale node in the blockchain network, and the node type of the first node will not be limited herein. Of course, in order to reduce the waste of the storage space of the first node, the first node in the embodiment of the present application may take a blockchain light node as an example, and the first node may synchronize the blockhead data in the blockchain ledger, and obtain the required blockhead data and the block data (for example, transaction data associated with the first node itself) that is partially authorized and visible through data interaction with the full-scale nodes (for example, the second node) in the blockchain network. Wherein the second node may be deployed with a smart contract (i.e., ticket contract) associated with the blockchain electronic ticket.

As shown in fig. 1, the node 10A may be respectively connected to the terminal devices in the terminal device cluster 1Y shown in fig. 1 through a network, so that each terminal device may interact with the node 10A through the network connection. The network connection is not limited to a connection manner, and may be directly or indirectly connected through a wired communication manner, may be directly or indirectly connected through a wireless communication manner, or may be other manners, which is not limited herein. As shown in fig. 1, the terminal device cluster 1Y may include a plurality of terminal devices, and the plurality of terminal devices may include a terminal device 100a, a terminal device 100b, terminal devices 100c, …, and a terminal device 100n.

The node 10A may also have a network connection relationship with the tax office management terminal 1000G shown in fig. 1, so that the tax office management terminal 1000G performs real-time statistics on the billing accumulated data volume of the service object corresponding to each terminal device based on the billing statistics service, so as to monitor the object risk status of each service object. In addition, the tax administration terminal 1000G may also have a network connection relationship with a second node in the blockchain network (i.e., any one of the consensus nodes in the blockchain network, e.g., node 10B) shown in fig. 1, such that upon detecting that a business object (e.g., an enterprise object) is at risk, the tax administration terminal 1000G sends a state change request to the node 10B to cause the node 10B to change the object risk state of the business object at risk from a first risk state (e.g., "no risk state") to a second risk state (e.g., "at risk state"). The object risk status of the business object may be stored in a blockchain ledger of the blockchain network shown in fig. 1. Because the second risk status may be used to indicate the failure of billing by the node 10B, this means that once the object risk status of the service object on the blockchain ledger is the second risk status, when a new service billing requirement exists for the subsequent service object, the node 10B intercepts the billing transaction corresponding to the new service billing requirement, thereby causing the failure of billing by the service object, so as to improve the real-time performance of risk management and control.

For ease of understanding, further, please refer to fig. 2, fig. 2 is a schematic diagram of a scenario for data interaction according to an embodiment of the present application. As shown in fig. 2, the node 20A in the embodiment of the present application may be a blockchain light node deployed with a management contract, and the node 20A may be the node 10A in the embodiment corresponding to fig. 1; the node 20B in the embodiment of the present application may be a consensus node deployed with a ticket contract, and the node 20B may be the node 20B in the embodiment corresponding to fig. 1 described above; the object terminal 200Z in the embodiment of the present application may be a terminal device used by a service object (e.g., an enterprise object), where the object terminal 200Z may be any one of the terminal device clusters in the embodiment corresponding to fig. 1, for example, the terminal device 100a; the tax administration terminal 2000G in the embodiment of the present application may be a computer device having an invoicing statistics service function, and the tax administration terminal 2000G may be the tax administration terminal 1000G in the embodiment corresponding to fig. 1.

It should be appreciated that the business object shown in fig. 2 may perform an invoicing operation with respect to the object terminal 200Z when an electronic ticket is required to be applied based on a business requirement (e.g., business procurement), so that the object terminal 200Z may generate a business invoicing request in response to the invoicing operation. The billing operation herein may refer to a triggering operation for executing the billing service, may include a touch operation such as clicking, long pressing, etc., and may also include a non-touch operation such as voice, gesture, etc., which will not be limited herein. Here, the service billing request may carry ticket information, such as basic information (purchaser name, address, contact, etc.) of the reimbursement object, basic information (seller name, address, contact, etc.) of the billing object, and basic information (for example, unit price, quantity, amount, etc.) associated with the service purchase. The bill information is acquired after the user authorization, and the bill information is acquired according to relevant laws and regulations and standards of relevant countries and regions.

Further, the target terminal 200Z performs step S21 to transmit the service billing request to the node 20A. When the node 20A generates the billing transaction corresponding to the service billing request, step S22 may be executed to send the billing transaction to the node 20B in the blockchain network, so that the node 20B may generate the billing result notification based on the object risk status of the service object. The object risk status may be stored in the blockchain ledger 2Q of fig. 2, where the blockchain ledger 2Q may be a blockchain ledger in the blockchain network where the node 20A and the node 20B are located.

It will be appreciated that if the risk status of the object obtained by the node 20B from the blockchain ledger 2Q is the second risk status (e.g., the "risky status"), the node 20B may determine that the business object has a potential safety hazard, and at this time, the node 20B may generate an invoicing notification (i.e., an invoicing failure notification) indicating an invoicing failure. Optionally, if the object risk status obtained by the node 20B from the blockchain ledger 2Q is the first risk status (for example, the "no risk status"), the node 20B may determine that the service object does not have a potential safety hazard, at this time, the node 20B may verify the billing transaction, and when the verification is successful, generate a billing notification (i.e. a billing success notification) for indicating that the billing is successful. The verification herein may include, among others, a validity verification of the node 20A (e.g., whether it belongs to an illegal node), a validity verification of ticket information (e.g., a label check, a parameter verification, etc.).

Further, the node 20B may perform step S23 to return the generated billing result notification to the node 20A. If the billing result notification received by the node 20A is a billing success notification, the node 20A may perform step S24 to transmit transaction data associated with the billing success notification to the tax administration terminal 2000G shown in fig. 2 based on the management contract deployed locally at the node 20A. At this time, the tax administration terminal 2000G may perform step S25 of determining an object risk state of the business object based on the received transaction data and the object information of the business object stored in the tax administration terminal 200G. The object information here may include, among others, the cumulative amount of invoices, the frequency of invoices, the reputation of invoices, etc. of the business object over a billing statistics period (e.g., 10 days, one month, half year, one year, etc.). If the tax administration terminal 2000G determines that the object risk status of the service object is a second risk status different from the first risk status, the tax administration terminal 2000G may perform step S26 in real time and send a status change request to the node 20B. It will be appreciated that, when the node 20B receives a status change request associated with a business object, the node 20B may perform step S27 to change the object risk status of the business object from the original first risk status to the second risk status based on the blockchain ledger 2Q.

It can be seen that, when the node 20A (i.e., the first node) in the embodiment of the present application receives the notification of success of invoicing, the transaction data associated with the notification of success of invoicing can be sent to the tax office management terminal 2000G in real time based on the locally deployed management contract, so that the tax office management terminal 2000G reconfirms the object risk status of the service object. Once the tax office management terminal 2000G detects that the object risk state of the service object needs to be changed, a state change request may be sent to the node 20B, so that the node 20B updates the object risk state of the service object on the blockchain ledger 2Q in real time, so that a subsequent service billing request of the service object may be effectively intercepted, thereby improving the real-time performance of risk management and control, so that a risk manager may take various measures and methods in time, and eliminate or reduce various possibilities of occurrence of a risk event, or reduce losses caused by occurrence of the risk event.

The embodiment of the application realizes the specific implementation manner of real-time wind control of the blockchain electronic bill by data interaction among the tax bureau management terminal, the first node (namely, the blockchain light node deployed with the management contract) and the second node (namely, the consensus node deployed with the bill contract) in the blockchain network, and can be seen in the embodiments corresponding to the following fig. 3-7.

Further, referring to fig. 3, fig. 3 is a flow chart of a data processing method according to an embodiment of the application. As shown in fig. 3, the method may be performed by a first node in the blockchain network, where the first node may have authority to perform ticket processing on a business object in a certain area (e.g., district, city, province), and the first node may be locally deployed with a smart contract (i.e., a management contract) associated with a blockchain electronic ticket, where the first node may be a blockchain light node in the blockchain network shown in fig. 1, e.g., the node 10A, and the method may at least include the following steps S101-S102:

step S101, when a business billing request of a business object is obtained, a billing transaction corresponding to the business billing request is sent to a second node in the blockchain network, so that the second node generates a billing result notice for returning to the first node based on the object risk state of the business object.

The object risk status may be stored in a blockchain ledger of the blockchain network. Specifically, when the business object needs to apply for the blockchain electronic ticket based on the business requirement, the object terminal may be used to perform an invoicing operation (e.g., a triggering operation for inputting ticket information). When the object terminal responds to the billing operation, a service billing request of the service object can be generated, and then the service billing request can be sent to a first node in the blockchain network, so that the first node performs information verification (including signature verification, parameter verification and the like) on the service billing request. The service billing request may include information to be signed and object signature information, where the object signature information is obtained by performing signature processing on the information to be signed by the object terminal based on an object private key of the service object. Wherein the information to be signed may include ticket information determined by the business object. Further, the first node can obtain an object public key corresponding to the service object from the blockchain ledger, and further can sign the object signature information based on the object public key to obtain a sign verification result. If the signature verification result indicates verification failure, the first node can directly generate prompt information for indicating the billing failure, and then the prompt information is returned to the object terminal. Optionally, if the signature verification result indicates that verification is successful, the first node needs to further perform parameter verification on the ticket information in the to-be-signed information to obtain a parameter verification result. If the parameter verification result indicates that verification is successful, the first node may generate an billing transaction corresponding to the service billing request, and then send the billing transaction to a second node in the blockchain network, so that the second node generates a billing result notification for returning to the first node based on the object risk state of the service object. Optionally, if the parameter verification result indicates that the verification fails, the first node does not need to generate an billing transaction corresponding to the service billing request, and does not need to perform service interaction with a second node in the blockchain network.

It is to be appreciated, among other things, that the blockchain ledger of the blockchain network can include an information registration block, where the information registration block can be utilized to store object registration information for business objects. For example, the tax office management terminal may generate an object information registration request when acquiring the object registration information of the service object, and may further send the object information registration request to a second node in the blockchain network. The object registration information is acquired after the authorization of the business object, and the acquisition of the object registration information is required to comply with relevant laws and regulations and standards of relevant countries and regions. The second node may perform packaging processing on the object registration information of the service object when the verification object information registration request is a legal request, so as to obtain a block to be verified to be written into the blockchain ledger, and further, the second node may broadcast the block to be verified to a third node (other consensus nodes except the second node) in the blockchain network, so that the third node performs consensus on the obtained block to be verified, and a consensus result for returning to the second node is obtained. If the consensus result exceeding the consensus threshold value indicates that the consensus is successful, the second node can determine that the blockchain node in the blockchain network achieves the consensus, and write the block to be verified into the blockchain ledger as the information registration block.

For ease of understanding, further, please refer to fig. 4, fig. 4 is a schematic diagram of a scenario in which object registration information is uplink according to an embodiment of the present application. As shown in fig. 4, the tax administration terminal 4000G in the embodiment of the present application may be a terminal device having an object registration management service, and the tax administration terminal 4000G may be the tax administration terminal 1000G in the embodiment corresponding to fig. 1 described above. The node 40B (i.e., the second node) in the embodiment of the present application may be any common node in the blockchain network, for example, the node 40B may be the node 10B in the embodiment corresponding to fig. 1. Each consensus node 410g in the consensus network shown in fig. 4 belongs to the same blockchain network as node 40B.

The blockchain ledger 4Q shown in fig. 4 may be one same blockchain shared by each of the consensus nodes in the blockchain network to which the node 40B belongs, and each of the consensus nodes may obtain information stored in each block in the blockchain ledger 4Q. The blockchain ledger 4Q includes a block 40a, a block 40b, a block …, a block 40n, and an information registration block, and the block 40a may be referred to as an originating block of the blockchain ledger 4Q. The information registration block in the blockchain ledger 4Q contains object registration information of the business object.

It is to be understood that, when the tax administration terminal 4000G obtains the object registration information (e.g., the contact information, the business address, the business scale, the floor space, the registered asset, the business, the cooperation business, etc.) of the business object (e.g., the business object a), the object information registration request 40q shown in fig. 4 may be generated, and the object information registration request 40q may be further transmitted to the node 40B. The node 40B may generate a business transaction (i.e., an information registration transaction) for writing the object registration information into the blockchain ledger 4Q based on the object registration information carried by the object information registration request 40Q. Further, the node 40B may obtain the block 40n with the largest generated timestamp from the blockchain ledger 4Q, and further may perform packaging processing on the information registration transaction to obtain a block to be verified to be written into the blockchain ledger 4Q. At this time, the node 40B may broadcast the block to be verified to other consensus nodes (e.g., the consensus node 410 g) on the blockchain network, so that the consensus node 410g performs consensus on the obtained block to be verified to obtain a consensus result.

If there is a consensus result exceeding a consensus threshold (e.g., 1/2) in the consensus results returned by the consensus node 410g indicating that the consensus is successful, the node 40B may determine that the blockchain node in the blockchain network has reached the consensus, and may then write the block to be verified as an information registration block into the blockchain ledger 4Q, that is, use the block to be verified as the next block of the block 40 n. The maximum generation timestamp of the information registration block is used for updating the maximum generation timestamp on the blockchain ledger 4Q. Because of the non-tamper property of the blockchain ledger 4Q, the security of storing the object registration information can be effectively improved.

It should be understood that when the first node performs information verification (including signature verification, parameter verification, etc.) on the service billing request, the first node may perform signature verification on the object signature information in the service billing request, and after the signature verification result indicates success, perform parameter verification on the ticket information in the to-be-signed information carried by the service billing request. For example, when the signature verification result obtained after the first node verifies the signature indicates that verification is successful, the first node may obtain the object registration information of the service object from the blockchain ledger. For example, because the first node is a blockchain light node in the blockchain network, the blockchain ledger locally stored by the first node does not include the complete blockchain database, so the first node may send a registration information acquisition request to a second node in the blockchain network in real time, so that the second node queries the complete blockchain ledger (for example, the information registration block shown in fig. 4) for the object registration information of the service object, and may return the object registration information to the first node. Optionally, in order to improve the verification efficiency, the first node may synchronize the object registration information of the service object to the local database in advance, so that the first node can acquire the object registration information more quickly when performing parameter verification.

Further, the first node can compare the acquired object registration information with the bill information to obtain a comparison result. If the comparison result indicates that the registration information of the object is inconsistent with the bill information, the first node can generate a parameter verification result for indicating verification failure, and generate first prompt information for indicating the service object to carry out information modification, and then the first prompt information can be sent to the object terminal corresponding to the service object, so that the object terminal returns the modified bill information. For example, the first prompt message may be "you submit a ticket with errors, please go to the xxx website to modify it. "such text information.

Optionally, if the comparison result indicates that the registration information of the object is consistent with the ticket information, the first node may generate a parameter verification result for indicating that verification is successful, and further may execute a transaction service for the service object based on the service billing request, and generate a billing transaction according to a transaction execution result of the transaction service.

For easy understanding, further, please refer to fig. 5, fig. 5 is a schematic diagram of a scenario for checking information of a service billing request according to an embodiment of the present application. As shown in fig. 5, the object terminal 500Z in the embodiment of the present application may be an object terminal used by a service object, and the object terminal 500Z may be any one of the terminal devices in the terminal device cluster in the embodiment corresponding to fig. 1, for example, the terminal device 100a. The node 50A (i.e., the first node) in the embodiment of the present application may be a blockchain light node in a blockchain network, for example, the node 50A may be the node 10A in the embodiment corresponding to fig. 1.

As shown in fig. 5, the object terminal 500Z may acquire ticket information input by the service object in response to the billing operation of the service object, and may further determine the to-be-signed information 51k shown in fig. 5 based on the ticket information. At this time, the object terminal 500Z may perform signature processing on the to-be-signed information 51k based on the object private key of the service object, to obtain object signature information 52k corresponding to the to-be-signed information 51k. It is understood that the target terminal 500Z may obtain a hash rule for the to-be-signed information 51k, where the hash rule may be a digest algorithm that is agreed in advance between the target terminal 500Z and other blockchain nodes (e.g., the node 50A) in the blockchain network. Accordingly, the object terminal 500Z may perform hash computation on the to-be-signed information 51k based on the hash computation rule to obtain digest information (e.g., digest information h) of the to-be-signed information 51k. The summary information h of the to-be-signed information 51k determined by the target terminal 500Z may be referred to as first summary information in the embodiment of the present application. Further, the object terminal 500Z may perform signature processing on the first digest information based on the object private key of the service object, so that the object signature information 52k shown in fig. 5 may be obtained.

Further, the object terminal 500Z may generate a service billing request 50q shown in fig. 5 based on the to-be-signed information 51k and the object signature information 52k, and then may send the service billing request 50q to the node 50A, so that the node 50A performs signature verification on the object signature information 52k based on the object public key corresponding to the object private key (i.e. the object public key of the service object), to obtain a signature verification result. It can be understood that, the node 50A may obtain the object public key of the service object from the blockchain ledger in the blockchain network, and further may perform signature verification on the object signature information 52k based on the object public key, to obtain the first summary information of the to-be-signed information 51 k. Meanwhile, the node 50A may also acquire the same hash rule as the target terminal 500Z, and perform hash computation on the to-be-signed information 51k, so that digest information (for example, digest information H) of the to-be-signed information 51k may be obtained. The summary information H of the to-be-signed information 51k determined by the node 50A may be referred to as second summary information in the embodiment of the present application.

At this time, the node 50A may compare the first digest information with the second digest information to obtain a signature verification result, so as to determine whether the to-be-signed information 51k is tampered. It may be appreciated that if the first summary information is different from the second summary information, the node 50A may determine that the verification result indicates verification failure, and at this time, the node 50A may determine that the target terminal 500Z is an illegal terminal, and determine the received service billing request 50q as an illegal request. At this time, the node 50A may directly generate a hint information indicating a failure of billing to return the hint information to the subject terminal 500Z.

Alternatively, if the first digest information is the same as the second digest information, the node 50A may determine that the verification result indicates that verification is successful, which means that the to-be-signed information 51k is not tampered, and the to-be-signed information 51k is actually sent by the target terminal 500Z, at this time, the node 50A may determine that the target terminal 500Z is a legal terminal, and determine the received service billing request 50q as a legal request. It will be appreciated that when the verification result determined by the node 50A indicates that verification is successful, the node 50A may further perform parameter verification on the ticket information in the to-be-signed information 51k to obtain a parameter verification result. The parameter verification herein may include verifying the accuracy of the ticket information, among other things. For example, the node 50A may obtain the object registration information (for example, the object registration information 5x shown in fig. 5) of the service object from the blockchain ledger, and further may compare the object registration information 5x with the ticket information to obtain the comparison result.

If the comparison result indicates that the ticket information is inconsistent with the object registration information 5x, the node 50A may generate a parameter verification result (i.e. a verification failure result) for indicating that the verification fails, and may further generate prompt information (for example, the prompt information 50T shown in fig. 5) for indicating that the service object performs information modification, so that the object terminal 500Z returns the modified ticket information. The information form of the prompt information here may include audio, text, video, etc., which will not be limited here. Optionally, if the comparison result indicates that the ticket information is consistent with the object registration information 5x, the node 50A may execute a transaction service (e.g., an invoicing service) for the service object based on the service invoicing request 50q, and may further generate an invoicing transaction 50J for forwarding to a second node in the blockchain network according to a transaction execution result of the transaction service.

Further, in order to effectively ensure the security of data transmission between the first node and the second node in the billing transaction, the first node may acquire a node public key of the second node in the blockchain network from the blockchain account book, so as to encrypt the billing transaction based on the node public key to obtain transaction encrypted data, and further may send the transaction encrypted data to the second node, so that the second node decrypts the transaction encrypted data based on the node private key of the second node to obtain the billing transaction. It will be appreciated that the second node, upon acquiring the invoicing transaction, may invoke a ticket contract disposed at the second node, and verify the invoicing transaction based on the ticket contract. The verification herein may include transaction format verification, verification of an invoicing field, verification of a signature based on an object public key of a business object, parameter verification (e.g., comparison between ticket information and object registration information of the business object), and the like. The embodiment of verifying the billing transaction by the second node may refer to the embodiment of verifying the information by the first node for performing the service billing request on the bill information, which will not be described in detail.

When the second node successfully verifies the billing transaction, the second node may further obtain an object risk status of the business object from a blockchain ledger of the blockchain network based on the ticket contract. For example, the second node may obtain, from a blockchain ledger of the blockchain network, a block currently having the largest generated timestamp, and may further obtain, from a state tree of the obtained block, an object risk state of the service object.

If the object risk state of the business object is the first risk state, the second node may perform packing and chaining on the billing transaction, and when the billing transaction is successfully written into the blockchain ledger, the second node may generate a billing success notification. Optionally, if the object risk status is the second risk status, the second node may directly generate the billing failure notification. Further, the second node may notify the billing success notification or the billing failure notification as a billing result notification for returning to the first node.

Step S102, if the invoicing result notification is an invoicing success notification, triggering a management contract deployed on the first node, and forwarding transaction data associated with the invoicing success notification to the tax office management terminal based on the management contract.

Wherein the invoicing success notification is generated by the second node when the subject risk status is the first risk status. Specifically, when receiving the billing result notification returned by the second node, the first node may directly forward the billing result notification to the object terminal. If the invoicing result notification returned by the second node is an invoicing success notification, the first node may trigger a management contract deployed on the first node, and may further forward transaction data associated with the invoicing success notification to the tax office management terminal based on the management contract. At this time, the tax administration terminal may determine an amount of billing accumulated data of the business object in the billing statistics period based on the billing statistics service, and may further determine an object risk status of the business object based on the amount of billing accumulated data and object information (e.g., whether to be added to an illegal billing list) of the business object. The illegal billing list refers to a blacklist generated by the tax administration management terminal. The illegal objects in the illegal billing list may be service objects that are abnormal in billing frequency (for example, service objects that are abnormally increased in billing frequency), service objects that are reported by others, service objects that have failed to operate (for example, bankruptcy objects), and the like, which will not be illustrated one by one. When the tax administration terminal detects that the object risk status of the business object associated with the transaction data is a second risk status different from the first risk status, the tax administration terminal may generate a status change request for transmission to the second node. Further, when the second node receives the state change request, the risk state of the object can be changed from the first risk state to the second risk state, wherein the second risk state is used for indicating that the second node fails to bill.

It may be understood that, when the second node receives the state change request sent by the tax office management terminal, the second node may generate a state change transaction associated with the service object based on the state change request. Further, the second node may obtain an initial block from the blockchain ledger with a maximum generated timestamp and determine an initial state tree in the initial block. Wherein the object risk state of the business object in the initial state tree is herein the first risk state. Further, the second node may change the first risk state in the initial state tree to the second risk state, and determine the changed initial state tree as the target state tree, so as to determine a state snapshot corresponding to the target state tree. Meanwhile, the second node may also determine a transaction hash value of the state change transaction, and may further determine a block hash value of the target block to be generated based on the transaction hash value. And then, the second node can carry out packing processing on the block hash value of the initial block, the state snapshot corresponding to the target state tree and the block hash value of the target block to obtain the target block. When a blockchain node in the blockchain network agrees with a target block, the second node may write the target block as a next block of the initial block into the blockchain ledger, wherein the generation timestamp in the target block may be used to update the maximum generation timestamp on the blockchain ledger.

Further, referring to fig. 6, fig. 6 is a flow chart of a data processing method according to an embodiment of the application. As shown in fig. 6, the method may be interactively performed by an object terminal corresponding to a business object, a tax office management terminal providing billing statistics service, a first node in a blockchain network, and a second node in the blockchain network. The target terminal may be any one of the terminal devices in the terminal device cluster shown in fig. 1, for example, the terminal device 100a. The tax administration terminal may be the tax administration terminal 1000G shown in fig. 1, the first node may be the node 10A shown in fig. 1, and the second node may be the node 10B shown in fig. 1. The method may include at least the following steps S201-S214:

In step S201, the object terminal transmits a service billing request to a first node in the blockchain network.

In step S202, the first node performs information verification based on the service billing request.

In step S203, when the verification is successful, the first node sends the billing transaction corresponding to the service billing request to the second node in the blockchain network.

In step S204, the second node obtains the object risk status of the service object from the blockchain ledger of the blockchain network based on the ticket contract, and generates the billing result notification based on the object risk status.

The invoicing result notification can be an invoicing failure notification or an invoicing success notification. The billing success notification is generated when the object risk state is the first risk state by the second node, and the billing failure notification is generated when the object risk state is the second risk state or the billing transaction verification fails. It will be appreciated that, when the billing result notification generated by the second node is a billing failure notification, the second node may perform the following steps S205 to S206:

in step S205, the second node transmits an invoicing failure notification to the first node.

In step S206, the first node forwards the billing failure notification to the target terminal.

It can be understood that, when the first node forwards the billing failure notification sent by the second node to the object terminal, the first node may generate, based on the billing failure reason indicated by the billing failure notification, target prompt information (for example, the second prompt information and the third prompt information) for sending to the object terminal, so that the service object corresponding to the object terminal performs corresponding operation based on the target prompt information, thereby improving the object operation experience.

If the billing result notification is a billing failure notification, and the billing failure notification indicates that the billing accumulated data volume of the service object in the billing statistics period reaches the data volume threshold, the first node may generate second prompt information for indicating the service object to perform data volume adjustment. Further, the first node may send the billing failure notification and the second prompt information to the object terminal corresponding to the service object, so that the object terminal generates the data amount adjustment request based on the second prompt information. When the first node receives the data volume adjustment request returned by the target terminal, the data volume adjustment request can be sent to the tax administration terminal, so that the tax administration terminal adjusts the data volume threshold of the service target.

For example, if the billing failure notification received by the first node indicates that the cumulative data volume of the business object for billing in one day reaches the data volume threshold (for example, 100), the second prompting message generated by the first node may be "the current cumulative data volume of the business object has reached the data volume threshold" to ask you to contact the related management object or go to the xxx website to readjust it. "such text information. It may be appreciated that, based on the second prompt information output by the object terminal, the service object may adjust the data volume of the service object from the initial data volume threshold (e.g. 100) to the target data volume threshold (e.g. 150), and input the adjustment reason (e.g. enterprise scale expansion) of the current adjustment data volume threshold, and then perform the confirmation operation after the input is completed. The target terminal may generate a data amount adjustment request for returning to the first node based on the target data amount threshold and the adjustment reason when responding to the confirmation operation. At this time, the first node may forward the data amount adjustment request to the tax administration terminal, so that the tax administration terminal adjusts the data amount threshold of the service object after verifying that the adjustment reason is legal.

If the billing result notification is a billing failure notification and the billing failure notification indicates that the service object has an abnormal risk, the first node may generate third prompt information for indicating the service object to perform risk complaint. Further, the first node may send the billing failure notification and the third prompt information to the object terminal corresponding to the service object, so that the object terminal performs risk complaints based on the third prompt information.

For example, the notification of the billing failure herein may indicate that the business object has an abnormal risk such as being reported by others or increasing the billing frequency, and at this time, the third prompt information generated by the first node may be text information such as "xx abnormal risk exists in the business object, and in order to ensure that the billing business is normally executed, please go offline to a tax office or xxx website to perform risk complaint as soon as possible.

Optionally, when the billing result notification generated by the second node is a billing success notification, the second node may skip to execute the following steps S207-S214 after executing step S204:

in step S207, the second node transmits an invoicing success notification to the first node.

In step S208, the first node forwards the billing success notification to the target terminal.

In step S209, the first node triggers a management contract deployed on the first node.

In step S210, the first node transmits transaction data associated with the invoicing success notification to the tax administration terminal based on the management contract.

In step S211, the tax administration management terminal determines an amount of accumulated data of invoices of the business object associated with the transaction data in the billing statistics period based on the billing statistics service.

In step S212, the tax administration terminal determines an object risk status of the service object based on the accumulated data amount of the invoices and the object information of the service object.

If the cumulative data volume of the invoices of the tax office management terminal does not reach the data volume threshold, and the illegal invoices list stored by the tax office management terminal does not contain the object information of the service object, the tax office management terminal can determine that the object risk state of the service object is still the first risk state stored by the current blockchain ledger.

Optionally, if the cumulative data volume of the invoices of the tax office management terminal reaches the data volume threshold, or if the object information of the service object exists in the illegal invoices list stored by the tax office management terminal, the tax office management terminal may determine that the object risk state of the service object is different from the first risk state stored by the current blockchain ledger, that is, the object risk state of the service object is the second risk state.

In step S213, the tax administration terminal sends a status change request to the second node when detecting that the object risk status of the business object is a second risk status different from the first risk status.

In step S214, the second node performs a state change on the object risk state of the service object in the blockchain ledger.

The specific implementation of the steps S201 to S214 may be referred to the description of the steps S101 to S102 in the embodiment corresponding to fig. 3, and will not be repeated here.

It will be appreciated that, in order to effectively reduce the risk of the association object having an association relationship with the business object (e.g., other enterprise objects having a cooperative relationship with the business object), the second node may generate the state change prompting information associated with the business object after performing step S214. The status change prompt message here may be a text message of "there is a risk in the XX business with which you are partnered, please partnership with caution". The second node may then send the state change hint information to the first node.

Further, the first node can acquire the association object with the association relation with the business object from the blockchain ledger, and further can acquire the contact information of the association object. The contact information may be object registration information of the associated object described in the blockchain ledger. It may be understood that the association object and the contact information of the association object may be obtained by the first node in advance and synchronously acquired from the second node, so as to be stored in the node memory of the first node, or may be sent by the second node together when sending the state change prompt information, which will not be limited herein. At this time, the first node may send the state change prompting information of the service object to the associated terminal corresponding to the associated object based on the contact information (for example, social account, mailbox, mobile phone number, etc.). It can be appreciated that, in the specific embodiment of the present application, related data such as contact information of an associated object is related, and when the above embodiment of the present application is applied to a specific product or technology, permission or consent of a user (i.e. the associated object) needs to be obtained, and the collection, use and processing of the related data all need to comply with related laws and regulations and standards of related countries and regions.

For ease of understanding, further, please refer to fig. 7, fig. 7 is a schematic diagram of an architecture for implementing real-time wind control of a blockchain electronic ticket according to an embodiment of the present application. As shown in fig. 7, the node 70A (i.e., the first node in the blockchain network) in the embodiment of the present application may be a blockchain light node deployed with a management contract, and the node 70A may be the node 10A in the embodiment corresponding to fig. 1 described above; the node 70B in the embodiment of the present application (i.e., the second node in the blockchain network) may be a consensus node deployed with ticket contracts, and the node 70B may be the node 70B in the embodiment corresponding to fig. 1 described above; the tax administration terminal 7000G in the embodiment of the present application may be a computer device having an billing statistics service function and an object registration management service function, and the tax administration terminal 7000G may be the tax administration terminal 1000G in the embodiment corresponding to fig. 1.

It should be appreciated that when the node 70A obtains a service billing request for a service object, the billing transaction corresponding to the service billing request may be sent to the node 70B in the blockchain network, so that the node 70B obtains the object risk status of the service object from the blockchain ledger based on the ticket contract, and may generate a billing result notification for returning to the node 70A. Wherein the ticket contracts of the node 70B may support control of the object risk status of the business object during the billing business.

If the billing result notification returned by the node 70B is a billing success notification, the node 70A may trigger a management contract deployed locally on the node 70A, and may forward transaction data associated with the billing success notification to the tax administration management terminal 7000G based on the management contract. Wherein the billing success notification herein is generated by the node 70B when the object risk status of the business object is a first risk status (e.g., a "no risk status").

Further, when the tax office management terminal 7000G receives the transaction data, the initial billing accumulated data amount of the service object in the billing statistics period can be obtained based on the billing statistics service, and further the billing accumulated data amount can be updated based on the transaction data, so as to obtain the updated billing accumulated data amount. If the updated cumulative data volume of invoices reaches the data volume threshold, or the object information of the service object indicates that the service object belongs to an abnormal object (i.e., the service object in the illegal invoicing list), the tax office management terminal 7000G may determine that the object risk status of the service object is a second risk status (e.g., "risk status"), and at this time, the tax office management terminal 7000G may send a status change request to the second node based on the object registration management service, so that the node 70B changes the object risk status of the service object from the first risk status to the second risk status.

In the embodiment of the application, when the first node in the blockchain network receives the notification of the billing result as the notification of the billing success, the transaction data associated with the notification of the billing success can be sent to the tax office management terminal in real time based on the locally deployed management contract, once the tax office management terminal detects that the object risk state of the business object needs to be changed, the state change request can be sent to the second node, so that the second node updates the object risk state of the business object to the second risk state in real time on the blockchain account, and as the second risk state is used for indicating the billing failure, the second node can rapidly intercept the billing requirement according to the object risk state (namely the second risk state) of the business object recorded in the blockchain account when the business object subsequently has the billing requirement, thereby improving the instantaneity of risk management and control. In addition, the network architecture of the embodiment of the application is simpler, and the problem that the block chain is not centralized enough is solved because a centralized billing agent is not needed to provide for wind control judgment.

Further, referring to fig. 8, fig. 8 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus 1 may be a computer program (comprising program code) running in a computer device, for example, the data processing apparatus 1 is an application software; the data processing device 1 may be adapted to perform the respective steps of the method provided by the embodiments of the application. As shown in fig. 8, the data processing apparatus 1 may operate at a first node in the blockchain network, which may be locally deployed with a smart contract (i.e., a management contract) associated with a blockchain electronic ticket, where the first node may be a blockchain light node in the blockchain network shown in fig. 1, e.g., node 10A. The data processing apparatus 1 may include: the system comprises an invoicing transaction sending module 11, a transaction data forwarding module 12, a first generating module 13, a first sending module 14, a data volume adjustment request receiving module 15, a second generating module 16, a second sending module 17, a change information obtaining module 18, a contact information obtaining module 19 and a change information sending module 20.

The billing transaction sending module 11 is configured to send, when a service billing request of a service object is obtained, a billing transaction corresponding to the service billing request to a second node in the blockchain network, so that the second node generates a billing result notification for returning to the first node based on an object risk state of the service object; the object risk status is stored in a blockchain ledger of the blockchain network.

Wherein, the billing transaction transmitting module 11 comprises: an invoicing request acquisition unit 111, a verification unit 112, a parameter verification unit 113, and an invoicing transaction transmission unit 114.

The billing request acquiring unit 111 is configured to acquire a service billing request of a service object; the business billing request comprises information to be signed and object signature information; the object signature information is obtained after signing the information to be signed based on an object private key of the service object; the information to be signed comprises bill information determined by the business object;

the signature verification unit 112 is configured to obtain an object public key corresponding to the service object from the blockchain ledger, and perform signature verification on the object signature information based on the object public key to obtain a signature verification result;

the parameter verification unit 113 is configured to perform parameter verification on the ticket information in the to-be-signed information if the verification result indicates that verification is successful, so as to obtain a parameter verification result.

Wherein the parameter verification unit 113 includes: a registration information acquisition subunit 1131, an information comparison subunit 1132, a verification success result generation subunit 1133, a verification failure result generation subunit 1134, and a hint information transmission subunit 1135.

The registration information obtaining subunit 1131 is configured to obtain, if the verification result indicates that the verification is successful, object registration information of the service object from the blockchain ledger;

the information comparison subunit 1132 is configured to compare the object registration information with the ticket information to obtain a comparison result;

the verification success result generating subunit 1133 is configured to generate a parameter verification result for indicating that the verification is successful if the comparison result indicates that the registration information of the object is consistent with the ticket information.

The verification failure result generating subunit 1134 is configured to generate a parameter verification result for indicating that verification fails and generate first prompt information for indicating that the service object performs information modification if the comparison result indicates that the registration information of the object is inconsistent with the ticket information;

the prompt information sending subunit 1135 is configured to send the first prompt information to the object terminal corresponding to the service object, so that the object terminal returns the modified ticket information.

The specific implementation manners of the registration information obtaining subunit 1131, the information comparing subunit 1132, the verification success result generating subunit 1133, the verification failure result generating subunit 1134 and the prompt information sending subunit 1135 may refer to the description of performing parameter verification on the service billing request in the embodiment corresponding to fig. 3, which will not be further described herein.

The billing transaction transmitting unit 114 is configured to transmit the billing transaction corresponding to the service billing request to the second node in the blockchain network if the parameter verification result indicates that the verification is successful.

Wherein the billing transaction transmitting unit 114 includes: an invoicing transaction generation subunit 1141, an encryption processing subunit 1142, and an encryption data transmission subunit 1143.

The billing transaction generating subunit 1141 is configured to execute a transaction service for the service object based on the service billing request if the parameter verification result indicates that the verification is successful, and generate a billing transaction according to a transaction execution result of the transaction service;

the encryption processing subunit 1142 is configured to obtain a node public key of a second node in the blockchain network from the blockchain ledger, and perform encryption processing on the open transaction based on the node public key to obtain transaction encrypted data;

The encrypted data transmitting subunit 1143 is configured to transmit the transaction encrypted data to the second node, so that the second node decrypts the transaction encrypted data based on the node private key of the second node, to obtain the billing transaction.

The specific implementation manner of the billing transaction generating sub-unit 1141, the encryption processing sub-unit 1142 and the encrypted data transmitting sub-unit 1143 may refer to the description of the data transmission of the billing transaction in the embodiment corresponding to fig. 3, and will not be described further herein.

The specific implementation manner of the billing request obtaining unit 111, the signing checking unit 112, the parameter checking unit 113 and the billing transaction transmitting unit 114 may refer to the description of step S101 in the embodiment corresponding to fig. 3, and will not be further described herein.

The transaction data forwarding module 12 is configured to trigger a management contract deployed on the first node if the invoicing result notification is an invoicing success notification, and forward transaction data associated with the invoicing success notification to the tax office management terminal based on the management contract; the invoicing success notice is generated by the second node when the object risk state is the first risk state; the tax office management terminal is used for sending a state change request to a second node when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object; the state change request is used for indicating the second node to change the object risk state from the first risk state to the second risk state; the second risk status is used to indicate a failure of the second node to issue an invoice.

The first generating module 13 is configured to generate a second prompt message for indicating that the service object performs data volume adjustment if the billing result notification is a billing failure notification and the billing failure notification indicates that the billing accumulated data volume of the service object in the billing statistics period reaches a data volume threshold;

the first sending module 14 is configured to send the billing failure notification and the second prompt information to an object terminal corresponding to the service object, so that the object terminal generates a data volume adjustment request based on the second prompt information;

the data volume adjustment request receiving module 15 is configured to receive a data volume adjustment request returned by the target terminal, and send the data volume adjustment request to the tax administration terminal, so that the tax administration terminal adjusts the data volume threshold of the service target.

The second generating module 16 is configured to generate third prompt information for indicating that the service object performs risk complaints if the billing result notification is a billing failure notification and the billing failure notification indicates that the service object has an abnormal risk;

the second sending module 17 is configured to send the billing failure notification and the third prompt information to the object terminal corresponding to the service object, so that the object terminal performs risk complaint based on the third prompt information.

The change information obtaining module 18 is configured to obtain state change prompt information sent by the second node; the state change prompt information is generated when the second node changes the object risk state from the first risk state to the second risk state;

the contact information obtaining module 19 is configured to obtain an association object having an association relationship with a service object from a blockchain ledger, and obtain contact information of the association object;

the change information sending module 20 is configured to send status change prompting information to the associated terminal corresponding to the associated object based on the contact information.

The specific implementation manner of the billing transaction sending module 11, the transaction data forwarding module 12, the first generating module 13, the first sending module 14, the data volume adjustment request receiving module 15, the second generating module 16, the second sending module 17, the change information obtaining module 18, the contact information obtaining module 19 and the change information sending module 20 may be referred to the description of step S101 to step S102 in the embodiment corresponding to fig. 3, and will not be described further herein. In addition, the description of the beneficial effects of the same method is omitted.

Further, referring to fig. 9, fig. 9 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing means 2 may be a computer program (comprising program code) running in a computer device, for example the data processing means 2 is an application software; the data processing device 2 may be adapted to perform the respective steps of the method provided by the embodiments of the application. As shown in fig. 9, the data processing apparatus 2 may operate at a second node in the blockchain network, which may be the node 10B shown in fig. 1 and described above. The data processing apparatus 2 may include: the system comprises an invoicing transaction acquisition module 100, a risk state acquisition module 200, a risk state change module 300, a registration request acquisition module 400, a registration information packaging module 500, a block broadcasting module 600 and an information registration block writing module 700.

The billing transaction acquisition module 100 is configured to acquire a billing transaction sent by a first node in a blockchain network; the billing transaction is generated by the first node based on the business billing request of the business object;

the risk state acquisition module 200 is configured to acquire an object risk state of a service object from a blockchain ledger of a blockchain network, and generate an invoicing result notification for returning to a first node based on the object risk state; the first node is used for forwarding transaction data associated with the billing success notification to the tax office management terminal based on the management contract deployed on the first node when the billing result notification is the billing success notification; the tax office management terminal is used for generating a state change request when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object.

The risk status acquisition module 200 includes: a risk status acquisition unit 2010, a success notification generation unit 2020, a failure notification generation unit 2030, and a result notification determination unit 2040.

The risk state acquiring unit 2010 is configured to invoke a ticket contract deployed on the second node, and acquire an object risk state of the business object from a blockchain ledger of the blockchain network based on the ticket contract;

The success notification generating unit 2020 is configured to generate a success notification of the invoicing when the invoicing transaction is successfully written into the blockchain ledger if the risk status of the object is the first risk status;

the failure notification generating unit 2030 is configured to generate an invoicing failure notification if the risk status of the object is the second risk status;

the result notification determination unit 2040 is for notifying the success of the invoicing or the failure of the invoicing as an invoicing result notification for returning to the first node.

The specific implementation manner of the risk status obtaining unit 2010, the success notification generating unit 2020, the failure notification generating unit 2030 and the result notification determining unit 2040 may refer to the description of the billing result notification in the embodiment corresponding to fig. 6, and will not be described in detail herein.

The risk state changing module 300 is configured to receive a state changing request sent by the tax office management terminal, and change the risk state of the object from a first risk state to a second risk state in the blockchain ledger; the second risk status is used to indicate a failure of the second node to issue an invoice.

Wherein, the risk status change module 300 includes: a state change request receiving unit 3010, an initial tree determining unit 3020, a target tree determining unit 3030, a block hash value determining unit 3040, a target block generating unit 3050, and a target block writing unit 3060.

The state change request receiving unit 3010 is configured to receive a state change request sent by the tax administration terminal, and generate a state change transaction associated with the business object based on the state change request;

the initial tree determining unit 3020, configured to obtain an initial block with the largest generation timestamp from the blockchain ledger, and determine an initial state tree in the initial block; the object risk state of the business object in the initial state tree is a first risk state;

the target tree determining unit 3030 is configured to change a first risk state in the initial state tree into a second risk state, determine the changed initial state tree as a target state tree, and determine a state snapshot corresponding to the target state tree;

the block hash value determining unit 3040 is configured to determine a transaction hash value of the state change transaction, and determine a block hash value of the target block to be generated based on the transaction hash value;

the target block generating unit 3050 is configured to perform a packing process on a block hash value of the initial block, a state snapshot corresponding to the target state tree, and a block hash value of the target block, to obtain the target block;

the target block writing unit 3060 is configured to take a target block as a next block of the initial block when a blockchain node in the blockchain network agrees with the target block; the generation timestamp in the target block is used to update the maximum generation timestamp on the blockchain ledger.

The specific implementation manner of the state change request receiving unit 3010, the initial tree determining unit 3020, the target tree determining unit 3030, the block hash value determining unit 3040, the target block generating unit 3050 and the target block writing unit 3060 may be referred to the description of step S214 in the embodiment corresponding to fig. 6, which will not be further described herein.

Wherein the blockchain ledger comprises an information registration block;

the registration request obtaining module 400 is configured to obtain an object information registration request sent by the tax office management terminal; the object information registration request carries the object registration information of the business object;

the registration information packaging module 500 is configured to package object registration information to obtain a block to be verified of a blockchain ledger to be written;

the block broadcasting module 600 is configured to broadcast a block to be verified to a third node in the blockchain network, so that the third node performs consensus on the obtained block to be verified to obtain a consensus result for returning to the second node;

the information registration block writing module 700 is configured to determine that the blockchain node in the blockchain network achieves the consensus if the consensus result exceeding the consensus threshold indicates that the consensus is successful in the consensus results, and write the block to be verified as the information registration block into the blockchain ledger.

The specific implementation manners of the billing transaction obtaining module 100, the risk status obtaining module 200, the risk status changing module 300, the registration request obtaining module 400, the registration information packaging module 500, the block broadcasting module 600 and the information registration block writing module 700 can be referred to the description of the steps S201-S214 in the embodiment corresponding to fig. 6, and the detailed description thereof will not be repeated here. In addition, the description of the beneficial effects of the same method is omitted.

Further, referring to fig. 10, fig. 10 is a schematic diagram of a computer device according to an embodiment of the application. As shown in fig. 10, the computer device 3000 may be the node 20A or the node 20B in the corresponding embodiment of fig. 2, and the computer device 3000 may include: at least one processor 3001, e.g., a CPU, at least one network interface 3004, a user interface 3003, memory 3005, at least one communication bus 3002. Wherein the communication bus 3002 is used to enable connected communications between these components. The user interface 3003 may include a Display screen (Display), a Keyboard (Keyboard), and the network interface 3004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others. The memory 3005 may be a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 3005 may also optionally be at least one memory device located remotely from the aforementioned processor 3001. As shown in fig. 10, the memory 3005, which is one type of computer storage medium, may include an operating system, a network communication module, a user interface module, and a device control application.

In the computer device 3000 shown in fig. 10, the network interface 3004 is mainly used for network communication; while the user interface 3003 is primarily used as an interface for providing input to a user; and the processor 3001 may be used to invoke device control applications stored in the memory 3005.

It should be understood that the computer device 3000 described in the embodiment of the present application may perform the description of the data processing method in the embodiment corresponding to fig. 3 or fig. 6, and may also perform the description of the data processing apparatus 1 in the embodiment corresponding to fig. 8 or the description of the data processing apparatus 2 in the embodiment corresponding to fig. 9, which are not repeated herein. In addition, the description of the beneficial effects of the same method is omitted.

The embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program includes program instructions, and when the program instructions are executed by a processor, implement the data processing method provided by each step in fig. 3 and fig. 6, and specifically, refer to the implementation manners provided by each step in fig. 3 and fig. 6, which are not repeated herein.

The computer readable storage medium may be the data transmission apparatus provided in any of the foregoing embodiments or an internal storage unit of a computer device, for example, a hard disk or a memory of the computer device. The computer readable storage medium may also be an external storage device of the computer device, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash card (flash card) or the like, which are provided on the computer device. Further, the computer-readable storage medium may also include both internal storage units and external storage devices of the computer device. The computer-readable storage medium is used to store the computer program and other programs and data required by the computer device. The computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.

Embodiments of the present application also provide a computer program product comprising a computer program stored in a computer readable storage medium. The processor of the computer device reads the computer program from the computer readable storage medium, and the processor executes the computer program, so that the computer device may perform the description of the data processing method or apparatus in the foregoing embodiments, which is not described herein. In addition, the description of the beneficial effects of the same method is omitted.

Further, referring to fig. 11, fig. 11 is a schematic structural diagram of a data processing system according to an embodiment of the present application. The data processing system 3 may comprise data processing means 1a and data processing means 2a. The data processing apparatus 1a may be the data processing apparatus 1 in the embodiment corresponding to fig. 8, and it is to be understood that the data processing apparatus 1a may be integrated in a first node in the blockchain network in the embodiment corresponding to fig. 1, where the first node may be locally deployed with an intelligent contract (i.e. a management contract) associated with a blockchain electronic ticket, where the first node may be a blockchain light node in the blockchain network shown in fig. 1, for example, the node 10A. Therefore, a detailed description will not be given here. The data processing device 2a may be the data processing device 2 in the embodiment corresponding to fig. 9, and it is understood that the data processing device 2a may be integrated in a second node in the blockchain network in the embodiment corresponding to fig. 1, and the second node may be the node 10B shown in fig. 1. Therefore, a detailed description will not be given here. In addition, the description of the beneficial effects of the same method is omitted. For technical details not disclosed in the embodiments of the data processing system according to the present application, please refer to the description of the method embodiments of the present application.

The terms first, second and the like in the description and in the claims and drawings of embodiments of the application are used for distinguishing between different objects and not for describing a particular sequential order. Furthermore, the terms "comprise," "include," and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, method, apparatus, article, or device that comprises a list of steps or elements is not limited to the list of steps or modules but may, in the alternative, include steps or modules not listed or inherent to such process, method, apparatus, article, or device.

Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the embodiments disclosed herein may be embodied in electronic hardware, in computer software, or in a combination of the two, and that the elements and steps of the examples have been generally described in terms of function in the foregoing description to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

The method and related apparatus provided in the embodiments of the present application are described with reference to the flowchart and/or schematic structural diagrams of the method provided in the embodiments of the present application, and each flow and/or block of the flowchart and/or schematic structural diagrams of the method may be implemented by computer program instructions, and combinations of flows and/or blocks in the flowchart and/or block diagrams. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks of one or more of the flowcharts and/or block diagrams. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart block or blocks of one or more of the flowcharts and/or block diagrams. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks.

The foregoing disclosure is illustrative of the present application and is not to be construed as limiting the scope of the application, which is defined by the appended claims.

Claims

1. A method of data processing, the method performed by a first node in a blockchain network, comprising:

when a business billing request of a business object is acquired, sending a billing transaction corresponding to the business billing request to a second node in the blockchain network, so that the second node generates a billing result notification for returning to the first node based on the object risk state of the business object; the object risk state is stored in a blockchain ledger of the blockchain network;

if the invoicing result notification is an invoicing success notification, triggering a management contract deployed on the first node, and forwarding transaction data associated with the invoicing success notification to a tax bureau management terminal based on the management contract; the invoicing success notification is generated by the second node when the subject risk state is a first risk state; the tax bureau management terminal is used for sending a state change request to the second node when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the service object; the state change request is used for indicating the second node to change the object risk state from the first risk state to the second risk state; the second risk status is used for indicating that the second node fails to issue an invoice.

2. The method according to claim 1, wherein the sending, when a service billing request of a service object is acquired, a billing transaction corresponding to the service billing request to a second node in the blockchain network includes:

acquiring a business billing request of a business object; the business billing request comprises information to be signed and object signature information; the object signature information is obtained by carrying out signature processing on the information to be signed based on an object private key of the service object; the information to be signed comprises bill information determined by the business object;

acquiring an object public key corresponding to the business object from the blockchain account book, and performing signature verification on the object signature information based on the object public key to obtain a signature verification result;

if the signature verification result indicates that verification is successful, carrying out parameter verification on bill information in the information to be signed to obtain a parameter verification result;

and if the parameter verification result indicates that verification is successful, sending an invoicing transaction corresponding to the service invoicing request to a second node in the blockchain network.

3. The method according to claim 2, wherein if the signature verification result indicates that verification is successful, performing parameter verification on the ticket information in the to-be-signed information to obtain a parameter verification result, including:

If the signature verification result indicates that verification is successful, object registration information of the business object is obtained from the blockchain ledger;

comparing the object registration information with the bill information to obtain a comparison result;

and if the comparison result indicates that the object registration information is consistent with the bill information, generating a parameter verification result for indicating that verification is successful.

4. A method according to claim 3, characterized in that the method further comprises:

if the comparison result indicates that the object registration information is inconsistent with the bill information, generating a parameter verification result for indicating verification failure, and generating first prompt information for indicating information modification of the business object;

and sending the first prompt information to an object terminal corresponding to the service object so as to enable the object terminal to return the modified bill information.

5. The method according to claim 2, wherein if the parameter verification result indicates that verification is successful, sending an invoicing transaction corresponding to the service invoicing request to a second node in the blockchain network, including:

if the parameter verification result indicates that verification is successful, executing transaction business aiming at the business object based on the business billing request, and generating billing transaction according to the transaction execution result of the transaction business;

Acquiring a node public key of a second node in the blockchain network from the blockchain account book, and carrying out encryption processing on the invoicing transaction based on the node public key to obtain transaction encryption data;

and sending the transaction encryption data to the second node so that the second node can decrypt the transaction encryption data based on the node private key of the second node to obtain the billing transaction.

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

if the billing result notification is a billing failure notification and the billing failure notification indicates that the billing accumulated data volume of the service object in the billing statistics period reaches a data volume threshold, generating second prompt information for indicating the service object to adjust the data volume;

sending the billing failure notification and the second prompt information to an object terminal corresponding to the service object, so that the object terminal generates a data volume adjustment request based on the second prompt information;

and receiving the data volume adjustment request returned by the object terminal, and sending the data volume adjustment request to the tax office management terminal so that the tax office management terminal adjusts the data volume threshold of the service object.

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

if the billing result notification is a billing failure notification and the billing failure notification indicates that the business object has abnormal risk, generating third prompt information for indicating the business object to perform risk complaints;

and sending the billing failure notification and the third prompt information to an object terminal corresponding to the service object, so that the object terminal carries out risk complaints based on the third prompt information.

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

acquiring state change prompt information sent by the second node; the state change prompt information is generated by the second node when the object risk state is changed from the first risk state to the second risk state;

acquiring an association object with an association relation with the business object from the blockchain account book, and acquiring contact information of the association object;

and based on the contact information, sending the state change prompt information to the associated terminal corresponding to the associated object.

9. A method of data processing, the method performed by a second node in a blockchain network, comprising:

Acquiring an invoicing transaction sent by a first node in the blockchain network; the billing transaction is generated by the first node based on a business billing request of a business object;

acquiring an object risk state of the business object from a blockchain account book of the blockchain network, and generating an invoicing result notice for returning to the first node based on the object risk state; the first node is used for forwarding transaction data associated with the invoicing success notification to a tax bureau management terminal based on a management contract deployed on the first node when the invoicing result notification is the invoicing success notification; the tax bureau management terminal is used for generating a state change request when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object;

receiving the state change request sent by the tax office management terminal, and changing the object risk state from the first risk state to the second risk state in the blockchain ledger; the second risk status is used for indicating that the second node fails to issue an invoice.

10. The method of claim 9, wherein the blockchain ledger includes an information registration block;

the method further comprises the steps of:

acquiring an object information registration request sent by the tax bureau management terminal; the object information registration request carries object registration information of the service object;

packaging the object registration information to obtain a block to be verified to be written into the blockchain ledger;

broadcasting the block to be verified to a third node in the blockchain network so that the third node performs consensus on the acquired block to be verified to obtain a consensus result for returning to the second node;

if the consensus result exceeding the consensus threshold value indicates successful consensus, determining that the blockchain nodes in the blockchain network reach consensus, and writing the block to be verified into the blockchain ledger as the information registration block.

11. The method of claim 9, wherein the obtaining the object risk status of the business object from the blockchain ledger of the blockchain network, and generating the billing result notification for returning to the first node based on the object risk status, comprises:

Invoking a ticket contract deployed on the second node, and acquiring an object risk state of the business object from a blockchain ledger of the blockchain network based on the ticket contract;

if the object risk state is the first risk state, generating an invoicing success notification when the invoicing transaction is successfully written into the blockchain ledger;

if the object risk state is the second risk state, generating an invoicing failure notification;

and taking the invoicing success notice or the invoicing failure notice as an invoicing result notice for returning to the first node.

12. The method of claim 9, wherein the receiving the status change request sent by the tax administration terminal changes the subject risk status from the first risk status to the second risk status in the blockchain ledger, comprising:

receiving the state change request sent by the tax bureau management terminal, and generating a state change transaction associated with the business object based on the state change request;

acquiring an initial block with the maximum generation timestamp from the blockchain account book, and determining an initial state tree in the initial block; the object risk state of the business object in the initial state tree is the first risk state;

Changing the first risk state in the initial state tree into the second risk state, determining the changed initial state tree as a target state tree, and determining a state snapshot corresponding to the target state tree;

determining a transaction hash value of the state change transaction, and determining a block hash value of a target block to be generated based on the transaction hash value;

packaging the block hash value of the initial block, the state snapshot corresponding to the target state tree and the block hash value of the target block to obtain the target block;

when a blockchain node in the blockchain network achieves consensus for the target block, the target block is used as a next block of the initial block; the generation time stamp in the target block is used to update the maximum generation time stamp on the blockchain ledger.

13. A data processing apparatus, comprising:

the billing transaction sending module is used for sending the billing transaction corresponding to the business billing request to a second node in the blockchain network when the business billing request of the business object is acquired, so that the second node generates a billing result notice for returning to the first node based on the object risk state of the business object; the object risk state is stored in a blockchain ledger of the blockchain network;

The transaction data forwarding module is used for triggering a management contract deployed on the first node if the invoicing result notification is an invoicing success notification, and forwarding transaction data associated with the invoicing success notification to a tax bureau management terminal based on the management contract; the invoicing success notification is generated by the second node when the subject risk state is a first risk state; the tax bureau management terminal is used for sending a state change request to the second node when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the service object; the state change request is used for indicating the second node to change the object risk state from the first risk state to the second risk state; the second risk status is used for indicating that the second node fails to issue an invoice.

14. A data processing apparatus, comprising:

the billing transaction acquisition module is used for acquiring billing transactions sent by a first node in the blockchain network; the billing transaction is generated by the first node based on a business billing request of a business object;

The risk state acquisition module is used for acquiring an object risk state of the business object from a blockchain account book of the blockchain network and generating an invoicing result notice for returning to the first node based on the object risk state; the first node is used for forwarding transaction data associated with the invoicing success notification to a tax bureau management terminal based on a management contract deployed on the first node when the invoicing result notification is the invoicing success notification; the tax bureau management terminal is used for generating a state change request when determining that the object risk state is a second risk state different from the first risk state based on the transaction data and the object information of the business object;

the risk state changing module is used for receiving the state changing request sent by the tax bureau management terminal and changing the object risk state from the first risk state to the second risk state in the blockchain ledger; the second risk state is used for indicating that the second node fails to issue an invoice.

15. A computer device, comprising: a processor and a memory;

the processor is connected to a memory, wherein the memory is configured to store a computer program, and the processor is configured to invoke the computer program to cause the computer device to perform the method of any of claims 1 to 12.

16. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program adapted to be loaded and executed by a processor to cause a computer device having the processor to perform the method of any of claims 1 to 12.

17. A computer program product, characterized in that it comprises a computer program stored in a computer readable storage medium, which computer program is adapted to be read and executed by a processor to cause a computer device with the processor to perform the method of any one of claims 1 to 12.