Bill processing method and device, computer equipment and storage medium

Abstract

The invention provides a bill processing method and device, computer equipment and a storage medium. The method is applied to a bill generation node corresponding to a first bill in a bill chain, the first bill is a finally generated bill in the bill chain, and the method comprises the following steps: obtaining bill checking demand information, the bill checking demand information comprising bill checking flow information indicating a bill verification process; generating a first ticket checking execution program code according to the ticket checking process information; acquiring bill modification information corresponding to the bill generation node, the private key data and second bill information corresponding to a second bill adjacent to the first bill in the bill chain; generating a bill signature corresponding to the bill generation node based on the private key data; and generating a first bill according to the first bill checking execution program code, the second bill information, the bill modification information and the bill signature. According to the embodiment of the invention, the bill processing flexibility can be improved.

Description

Technical Field

[0001] The present disclosure relates to the technical field of bill processing, and particularly to a bill processing method, apparatus, computer device, and storage medium. Background Art

[0002] With the development of Internet technology, various application services in different scenarios of people's lives have begun to emerge continuously. For example, in the payment application scenario, electronic bills can be generated according to the specific information of the payment operation as the payment settlement vouchers in the application. By verifying the electronic bills, the security of payment settlement can be improved.

[0003] In some payment scenarios, such as in the resource procurement scenario, when a resource supplier supplies resources to a purchaser, the ticket verification logic obtained when the ticket is generated for the first time can be stored in the form of a smart contract. In this way, the ticket verification party can verify the subsequent generated electronic bills by calling the smart contract interface.

[0004] However, this way of processing bills in combination with smart contracts has poor flexibility. Summary of the Invention

[0005] Embodiments of the present disclosure provide a bill processing method, apparatus, computer device, and storage medium. The bill processing method can improve the flexibility of bill processing.

[0006] According to one aspect of the present disclosure, there is provided a bill processing method, which is applied to a bill generation node corresponding to a first bill in a bill chain. The first bill is the last generated bill in the bill chain. The method includes:

[0007] Obtain ticket verification requirement information, where the ticket verification requirement information includes ticket verification process information indicating the ticket verification process;

[0008] Generate first ticket verification execution program code according to the ticket verification process information;

[0009] Obtain the bill modification information corresponding to the bill generation node, the private key data, and the second bill information corresponding to a second bill adjacent to the first bill in the bill chain;

[0010] Generate a bill signature corresponding to the bill generation node based on the private key data;

[0011] Generate the first bill according to the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0012] According to one aspect of the present disclosure, there is provided a bill processing method, which is applied to a ticket verification node. The method includes:

[0013] Obtain a first bill to be verified and public key data corresponding to the bill generation node that generated the first bill, where the first bill is the last generated bill in the bill chain to be verified;

[0014] Verify the bill signature corresponding to the first bill based on the public key data to obtain a verification result;

[0015] When the verification result indicates that the verification is qualified, perform bill parsing on the first bill to obtain the first bill verification execution program code and bill modification information corresponding to the first bill;

[0016] Perform code verification on the first bill verification execution program code according to the bill modification information to obtain a bill verification result.

[0017] According to one aspect of the present disclosure, there is provided a bill processing device, which is applied to a bill generation node corresponding to the first bill in a bill chain, where the first bill is the last generated bill in the bill chain, and the device includes:

[0018] A first acquisition unit for acquiring bill verification requirement information, where the bill verification requirement information includes bill verification process information indicating the bill verification process;

[0019] A code generation unit for generating a first bill verification execution program code according to the bill verification process information;

[0020] A second acquisition unit for acquiring bill modification information, private key data corresponding to the bill generation node, and second bill information corresponding to a second bill adjacent to the first bill in the bill chain;

[0021] A signature generation unit for generating a bill signature corresponding to the bill generation node based on the private key data;

[0022] A bill generation unit for generating the first bill according to the first bill verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0023] Optionally, in some embodiments, the code generation unit includes:

[0024] An information extraction subunit for extracting information from the bill verification process information to obtain bill verification process interaction information and bill verification process logic information;

[0025] A code generation subunit for generating a first bill verification execution program code according to the bill verification process interaction information and the bill verification process logic information.

[0026] Optionally, in some embodiments, the code generation subunit is specifically configured to:

[0027] Obtain code generation prompt words;

[0028] Based on the code generation prompt words, the ticket verification process interaction information, and the ticket verification process logic information, call a preset large language model for code generation to obtain the first ticket verification execution program code.

[0029] Optionally, in some embodiments, after generating the first ticket verification execution program code according to the ticket verification process information, the apparatus further includes:

[0030] A fourth acquisition unit, configured to acquire ticket verification requirement modification information, where the ticket verification requirement modification information includes ticket verification process modification information indicating the ticket verification process;

[0031] A first update unit, configured to update the first ticket verification execution program code according to the ticket verification process modification information to obtain a second ticket verification execution program code;

[0032] A second update unit, configured to update the first ticket according to the second ticket verification execution program code.

[0033] Optionally, in some embodiments, the ticket generation unit is specifically configured to:

[0034] Perform a hash process on the second ticket information to obtain ticket hash data corresponding to the second ticket information;

[0035] Generate the first ticket based on the ticket hash data, the first ticket verification execution program code, the ticket modification information, and the ticket signature.

[0036] Optionally, in some embodiments, the signature generation unit is specifically configured to:

[0037] Perform a digest calculation on the ticket modification information according to a preset digest algorithm to obtain a first digest;

[0038] Encrypt the first digest based on the private key data to obtain the ticket signature corresponding to the ticket generation node.

[0039] Optionally, in some embodiments, the signature generation unit is specifically further configured to:

[0040] Obtain the node permission information of the ticket generation node;

[0041] Generate the ticket signature corresponding to the ticket generation node based on the private key data and the node permission information.

[0042] Optionally, in some embodiments, the ticket generation unit is specifically further configured to:

[0043] Perform a pre-execution check on the first ticket verification execution program code to obtain a code pre-execution check result;

[0044] When the code pre-execution check result indicates a successful check, generate the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature.

[0045] Optionally, in some embodiments, the ticket generation unit is further specifically configured to:

[0046] Generate a ticket based on the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature in accordance with a preset ticket format to obtain a candidate ticket corresponding to the ticket generation node;

[0047] Perform serialization processing on the candidate ticket to obtain the first ticket.

[0048] According to one aspect of the present disclosure, there is provided a ticket processing device, which is applied to a ticket verification node. The device includes:

[0049] A third acquisition unit, configured to acquire a first ticket to be verified and public key data corresponding to a ticket generation node that generates the first ticket, where the first ticket is the last generated ticket in the ticket chain to be verified;

[0050] A signature verification unit, configured to perform signature verification on the ticket signature corresponding to the first ticket based on the public key data to obtain a signature verification result;

[0051] A ticket parsing unit, configured to, when the signature verification result indicates a successful signature verification, parse the first ticket to obtain the first ticket verification execution program code and ticket modification information corresponding to the first ticket;

[0052] A code verification unit, configured to perform code verification on the first ticket verification execution program code according to the ticket modification information to obtain a ticket verification result.

[0053] Optionally, in some embodiments, the code verification unit is specifically configured to:

[0054] Acquire ticket verification data;

[0055] Perform code verification on the first ticket verification execution program code based on the ticket verification data and the ticket modification information to obtain a ticket verification result.

[0056] Optionally, in some embodiments, the signature verification unit is specifically configured to:

[0057] Decrypt the ticket signature corresponding to the first ticket based on the public key data to obtain a decryption result;

[0058] Calculate a second digest for the bill modification information according to a preset digest algorithm.

[0059] Determine the signature verification result of the bill signature according to the comparison result between the decryption result and the second digest.

[0060] According to one aspect of the present disclosure, a computer device is provided, including a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the bill processing method described above is implemented.

[0061] According to one aspect of the present disclosure, a computer-readable storage medium is provided. The storage medium stores a computer program, and when the computer program is executed by a processor, the bill processing method described above is implemented.

[0062] According to one aspect of the present disclosure, a computer program product is provided. The computer program product includes a computer program, and the computer program is read and executed by a processor of a computer device, so that the computer device executes the bill processing method described above.

[0063] The bill processing method provided by the embodiments of the present disclosure includes: obtaining ticket verification requirement information, where the ticket verification requirement information includes ticket verification process information indicating a ticket verification process, and generating ticket verification execution program code according to the ticket verification process information; further, obtaining bill modification information corresponding to a bill generation node, private key data, and second bill information corresponding to a second bill adjacent to the first bill in the bill chain; generating a bill signature corresponding to the bill generation node based on the private key data; further, generating a first bill corresponding to the bill generation node in the bill chain according to the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature, where the first bill is the last generated bill in the bill chain.

[0064] In the process of generating the first bill based on the bill generation node in the bill chain in the embodiments of the present disclosure, ticket verification execution program code can be generated according to the ticket verification process information, and then the ticket verification execution program code is encapsulated in the bill and sent to the ticket verification node. In this way, the ticket verification node can perform ticket verification based on the ticket verification program execution code. Since the ticket verification program execution code has the advantages of being easy to modify and flexible to process, the flexibility of bill processing can be achieved.

[0065] Other features and advantages of the present disclosure will be described in the following description, and some of them will become obvious from the description or be understood by implementing the present disclosure. The objectives and other advantages of the present disclosure can be realized and obtained by the structures specifically pointed out in the description, claims, and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0066] The accompanying drawings are used to provide a further understanding of the technical solutions of the present disclosure, and constitute a part of the specification. Together with the embodiments of the present disclosure, they are used to explain the technical solutions of the present disclosure, and do not constitute a limitation to the technical solutions of the present disclosure.

[0067] Figure 1 It is a system architecture diagram applied to the bill processing method according to an embodiment of the present disclosure;

[0068] Figure 2 It is a schematic flowchart of the bill processing method according to an embodiment of the present disclosure applied to the bill generation node corresponding to the first bill in the bill chain;

[0069] Figure 3 It is a bill verification schematic diagram of the bill processing method provided by the related art;

[0070] Figure 4 It is a schematic process diagram of full-link data anti-tampering based on JS scripts according to an embodiment of the present disclosure;

[0071] Figure 5 It is a schematic principle diagram of the bill generation node generating the first bill according to an embodiment of the present disclosure;

[0072] Figure 6 It is a schematic structural diagram of adding bills in the bill chain to form a chain relationship according to an embodiment of the present disclosure;

[0073] Figure 7 It is a schematic flowchart of the bill processing method according to an embodiment of the present disclosure applied to the ticket verification node;

[0074] Figure 8 It is a schematic process diagram of logical verification based on the bill chain and JS scripts according to an embodiment of the present disclosure;

[0075] Figure 9 It is a specific schematic flowchart of the bill processing method according to an embodiment of the present disclosure;

[0076] Figure 10 It is a module diagram of the bill processing device applied to the bill generation node according to an embodiment of the present disclosure;

[0077] Figure 11 It is a module diagram of the bill processing device applied to the ticket verification node according to an embodiment of the present disclosure;

[0078] Figure 12 It is a terminal structure diagram for implementing the various methods according to an embodiment of the present disclosure;

[0079] Figure 13 It is a server structure diagram for implementing the various methods according to an embodiment of the present disclosure. Detailed implementation manners

[0080] In order to make the objectives, technical solutions and advantages of the present disclosure clearer and more understandable, the present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present disclosure, and are not used to limit the present disclosure.

[0081] Before further elaborating on the embodiments of the present disclosure, the nouns and terms involved in the embodiments of the present disclosure are described. The nouns and terms involved in the embodiments of the present disclosure are applicable to the following explanations:

[0082] Artificial intelligence: It is the theory, method, technology and application system that uses digital computers or machines controlled by digital computers to simulate, extend and expand human intelligence, perceive the environment, acquire knowledge and use knowledge to obtain target results. In other words, artificial intelligence is a comprehensive technology in computer science. It attempts to understand the essence of intelligence and produce a new intelligent machine that can respond in a way similar to human intelligence. Artificial intelligence also studies the design principles and implementation methods of various intelligent machines, enabling the machines to have the functions of perception, reasoning and decision-making. Artificial intelligence technology is an interdisciplinary subject, involving a wide range of fields, including both hardware-level technologies and software-level technologies. The basic technologies of artificial intelligence generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, and mechatronics. The software technologies of artificial intelligence mainly include several major directions such as computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning. With the research and progress of artificial intelligence technology, artificial intelligence technology has been studied and applied in multiple fields. For example, common ones include smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, driverless, autonomous driving, drones, robots, smart healthcare, smart customer service, etc. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0083] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, and encryption algorithms. Blockchain is a distributed ledger technology in the field of information technology. Since the ledger is distributedly stored and the blocks are consensus-based, it has characteristics such as immutability, traceability, and co-maintenance. Essentially, blockchain is a database that can achieve decentralization. It is a string of data blocks generated by using cryptographic methods. Each data block contains information about a batch of transactions, which is used to verify the validity (anti-counterfeiting) of the information and link to the previous block.

[0084] Smart contract: A computer protocol designed to disseminate, verify, or execute contracts in an information-based manner. Smart contracts allow for the execution of trustworthy transactions without a third party, and these transactions can be witnessed and are irreversible.

[0085] Issuing a ticket: Refers to the authoritative certificate generated after completing logical verification (such as user password verification, SMS verification, face recognition, etc.). The process of issuing a ticket clearly indicates that an operation on specific business data has been effectively executed, and the generated ticket can be used as evidence that the corresponding business logic verification for this operation has been completed.

[0086] Verifying a ticket: Refers to the process of verifying the legality, validity, and ownership of a ticket, aiming to confirm that the business operation it represents has indeed undergone and successfully passed all necessary logical verification steps, ensuring the legitimacy and effectiveness of this operation.

[0087] Software Development Kit (SDK): Refers to a software development kit provided for developers, which is a collection of development tools used to build application software for specific software packages, software frameworks, hardware platforms, operating systems, etc. The Ticket Chain SDK aims to simplify the development process of Ticket Chain applications, enabling developers to more conveniently create, deploy, and maintain ticket solutions. By using the Ticket Chain SDK, developers can utilize the pre-built components and functions it provides, avoiding writing all the code from scratch, thus saving time and resources.

[0088] Key Management Service (KMS): Used to issue the keys required for hash authentication in tickets.

[0089] With the development of Internet technology, various application services in different scenarios of people's lives have begun to emerge continuously. For example, in the payment application scenario, the ticket issuer can generate an electronic ticket based on the specific information of the payment operation as the payment settlement voucher in the application. The ticket is equivalent to an identity certificate, which can contain key elements of the user or the request, as well as the signature after using the key to perform hash authentication on the ticket information. By verifying the electronic ticket, the ticket verifier can ensure whether the ticket has been tampered with, reused, or expired, thereby enhancing the security of payment settlement.

[0090] In some payment scenarios, such as in the supply chain finance scenario, when resource supplier A supplies resources to purchaser B, a bill of exchange can be issued to purchaser B at the same time. This bill of exchange forms a single-node bill at the node corresponding to resource supplier A. This single-node bill can contain information about resource supplier A as the drawer, such as the issue date, the issue amount (the amount of the goods payment), the payee (i.e., purchaser B), and other key elements. At the same time, resource supplier A can store the ticket verification logic obtained when generating the bill for the first time in the form of a smart contract. In this way, the ticket verification party can verify the subsequent generated electronic bill by calling the smart contract interface.

[0091] However, since the code and logic corresponding to the smart contract containing the ticket verification logic are immutable after deployment. If it is necessary to update or modify the ticket verification logic, a new smart contract must be redeployed, resulting in additional complexity and cost. Thus, this way of processing bills in combination with smart contracts has poor flexibility.

[0092] To solve the problem of poor flexibility in the way of processing bills in combination with smart contracts in the above scenario, the present disclosure provides a bill processing method, aiming to improve the flexibility of bill processing.

[0093] System architecture and scenario description of the application of the embodiments of the present disclosure

[0094] Figure 1 It is a system architecture diagram applied to the bill processing method according to the embodiments of the present disclosure. It includes a terminal 110, the Internet 120, a gateway 130, a server 140, etc.

[0095] The terminal 110 includes various device forms such as a desktop computer, a laptop, a PDA (Personal Digital Assistant), a mobile phone, a vehicle-mounted terminal, a home theater terminal, a dedicated terminal, a smart voice interaction device, a smart home appliance, or an aircraft. In addition, the terminal 110 can be a single device or a collection of multiple devices. For example, multiple devices are connected through a local area network and share a display device for collaborative work, jointly constituting a terminal 110. The terminal 110 can communicate with the Internet 120 in a wired or wireless manner to exchange data.

[0096] Server 140 refers to a computer system that can provide certain services to terminal 110. Compared with ordinary terminal 110, server 140 has higher requirements in terms of stability, security, performance, etc. Server 140 can be a high-performance computer in a network platform, a cluster of multiple high-performance computers, a part (such as a virtual machine) partitioned from a high-performance computer, a combination of parts (such as virtual machines) partitioned from multiple high-performance computers, etc. In the embodiments of the present disclosure, server 140 specifically provides a storage function, that is, here server 140 can be a database node of a distributed database, and there are multiple servers 140 in the present disclosure that form a cluster of the distributed database.

[0097] The gateway 130 is also called an internetwork connector and a protocol converter. The gateway realizes network interconnection at the transport layer and is a computer system or device that acts as a converter. Between two systems that use different communication protocols, data formats, or languages, and even have completely different architectures, the gateway is a translator. At the same time, the gateway can also provide filtering and security functions. The messages sent by terminal 110 to server 140 need to be processed and forwarded by gateway 130. The messages sent by server 140 to terminal 110 also need to be processed and forwarded by gateway 130. In the embodiments of the present disclosure, terminal 110 can send a ticket processing request to server 140 through gateway 130, and server 140 can return a ticket processing result to terminal 110 through gateway 130.

[0098] The ticket processing method provided by the embodiments of the present disclosure can be implemented in terminal 110, can also be implemented in server 140, or can be partially implemented in terminal 110 and partially implemented in server 140.

[0099] When the ticket processing method provided by the embodiments of the present disclosure is implemented in terminal 110, in response to the ticket processing task performed by the target object in terminal 110, terminal 110 can first obtain ticket verification requirement information, where the ticket verification requirement information includes ticket verification process information indicating the ticket verification process, and generate a first ticket verification execution program code according to the ticket verification process information; further, terminal 110 can obtain ticket modification information corresponding to the ticket generation node, private key data, and second ticket information corresponding to the second ticket adjacent to the first ticket in the ticket chain; further, terminal 110 generates a ticket signature corresponding to the ticket generation node based on the private key data; finally, terminal 110 can generate a first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature.

[0100] When the bill processing method provided by the embodiments of the present disclosure is implemented in the server 140, in response to a bill processing task performed by a target object in the server 140, the server 140 may first obtain bill verification requirement information, where the bill verification requirement information includes bill verification process information indicating a bill verification process, and generate first bill verification execution program code according to the bill verification process information; further, the server 140 may obtain bill modification information corresponding to a bill generation node, private key data, and second bill information corresponding to a second bill adjacent to the first bill in a bill chain; further, the server 140 may generate a bill signature corresponding to the bill generation node based on the private key data; finally, the server 140 may generate a first bill according to the first bill verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0101] When part of the bill processing method provided by the embodiments of the present disclosure is implemented in the terminal 110 and part is implemented in the server 140, in response to a bill processing task performed by a target object in the terminal 110, the terminal 110 may first obtain bill verification requirement information, where the bill verification requirement information includes bill verification process information indicating a bill verification process, and then the terminal 110 may send the bill verification requirement information to the server 140. Further, the server 140 may generate first bill verification execution program code according to the bill verification process information; afterwards, the terminal 110 may send the obtained bill modification information corresponding to the bill generation node, private key data, and second bill information corresponding to the second bill adjacent to the first bill in the bill chain to the server 140. Then, the server 140 may generate a bill signature corresponding to the bill generation node based on the private key data, generate a first bill according to the first bill verification execution program code, the second bill information, the bill modification information, and the bill signature, and send the first bill to the terminal 110.

[0102] The bill processing method provided by the embodiments of the present disclosure can be applied to bill processing tasks in various application services, and can specifically be applied to bill processing tasks in resource procurement applications, bill processing tasks in copyright registration applications, and other bill processing tasks in various Internet applications.

[0103] For example, when the bill processing method provided by the embodiments of the present disclosure is applied to the bill processing task in the resource procurement application, the bill verification requirement information for the resource procurement bill can be obtained first. The bill verification requirement information includes the bill verification process information indicating the bill verification process. Then, the first bill verification execution program code is generated according to the bill verification process information. Further, the bill modification information, private key data corresponding to the bill generation node, and the second bill information corresponding to the second bill adjacent to the resource procurement bill in the bill chain are obtained, and the bill signature corresponding to the bill generation node is generated based on the private key data. Further, the resource procurement bill is generated according to the first bill verification execution program code, the second bill information, the bill modification information, and the bill signature. In the process of generating the first bill based on the bill generation node in the bill chain in the embodiments of the present disclosure, the bill verification execution program code can be generated according to the bill verification process information, and then the bill verification execution program code is encapsulated in the bill and sent to the bill verification node, so that the bill verification node can perform bill verification based on the bill verification program execution code. Since the bill verification program execution code has the advantages of being easy to modify and flexible to process, the flexibility of bill processing can be realized.

[0104] The above example does not limit the protection scope of this case.

[0105] General description of the embodiments of the present disclosure

[0106] According to an embodiment of the present disclosure, a bill processing method is provided. As Figure 2 shown, it is a flowchart of a bill processing method provided by the present disclosure. This method is applied to the bill generation node corresponding to the first bill in the bill chain. The first bill is the last generated bill in the bill chain. This method can be executed by a computer device, and the computer device can specifically be a terminal or a server. The bill processing method may include:

[0107] Step 210, obtain bill verification requirement information.

[0108] Before introducing the bill processing method provided by the present disclosure in detail, the bill processing methods provided in the related technologies can be introduced in detail. The related technologies usually perform bill processing based on the Blockchain Virtual Machine (BVM) to achieve the logical anti-tampering of bills. As Figure 3As shown in the figure, it is a schematic diagram of a bill verification of the bill processing method provided by the related technology. Among them, the related technology provides a runtime environment on the basis of the blockchain structure, stores the logical code to be executed in the form of a smart contract, and ensures its immutability through cryptography and consensus mechanisms. A smart contract refers to the code automatically executed on the blockchain platform, and different blockchains have different forms of smart contract languages that can be accessed. Moreover, the immutability of the smart contract is guaranteed by the nodes in multiple distributed networks on the blockchain through the consensus protocol. The specific process is as follows: First, the bill issuer publishes the smart contract, that is, submits the verification logic of the bill to the virtual machine 310 (the blockchain virtual machine shown in the figure) in the form of smart contract code; then, the blockchain virtual machine can convert the smart contract code (a high-level language) into bytecode (a low-level language) for serialization storage; after that, the bill checker verifies the bill by calling the smart contract interface and passing in the expected parameters as input parameters.

[0109] However, the above bill processing method based on the blockchain virtual machine has some deficiencies: (1) Lack of flexibility: This is because after the smart contract containing the verification logic code is deployed, its code and logic cannot be changed. If it is necessary to update or modify the bill verification logic, a new smart contract must be redeployed, resulting in poor flexibility in bill processing; (2) High development and maintenance costs: This is because the smart contract languages required by the current blockchain frameworks are often specific, and most bill processing scenarios are simple financial calculations that do not require complex operation logics, increasing the access development costs. In addition, if the bill processing object chooses to build a private chain by itself, the entire virtual machine needs to be built and complex issues such as resource consumption, consensus algorithms, and distributed consistency of the related peer-to-peer (P2P) communication need to be considered, which is a functional redundancy for the bill processing business scenario.

[0110] To solve the problem of poor flexibility in the way of processing bills by combining smart contracts in the above scenario, the present disclosure provides a bill processing method in order to improve the flexibility of bill processing.

[0111] A bill chain is a bill authentication system that prevents errors and tampering throughout the entire link based on a chain structure. Among them, a single-node bill is a bill obtained by performing a trusted signature on a set of key element data. On this basis, multiple independent business modules can expand or verify the original bill structure. Therefore, by implementing a multi-bill chain structure, the subsequent appended bill will perform a hash, that is, a trusted signature, on the previous bill node, and multiple bills form a bill chain structure that prevents tampering throughout the entire link through layer-by-layer authentication. In the context of the bill chain, a single-node bill can be understood as a bill record formed at a specific link in the process of bill circulation, representing the status and relevant information of the bill at that node. The bill processing method of the present disclosure can be applied to the bill generation node corresponding to the first bill in the bill chain, and the first bill is the last generated bill in the bill chain. When a bill is appended to the current bill generation node in the bill chain, the bill generation node is updated to the node corresponding to the appended bill, and the bill generated based on the appended bill is equivalent to the new first bill. In this way, the bill verification node can verify the generated first bill.

[0112] It should be noted that a business module refers to a module that implements business logic. The bill verification party can put forward some requirements in terms of business logic according to specific business scenarios, such as the bill must be used within a specific time range, and the bill amount must meet specific calculation rules, etc. In the bill chain system of the present disclosure, each business logic can respectively correspond to a complete link (that is, from the use object initiating a call until the final background returns a result to achieve end-to-end verification of the entire link), so as to implement the functions of different business modules. Therefore, the bill issuance and verification process can be described by the call link between modules. Key elements refer to the core business data to be verified corresponding to the business modules one by one, such as bill amount, information of both parties in resource transfer, etc.

[0113] Among them, the bill verification requirement information refers to the verification requirements and conditions required for verifying the first bill. The bill verification requirement information can be sourced from the bill verification party, the bill issuance party, or default settings, without limitation. The bill verification requirement information specifically includes the source, format, verification target, security requirements, user interaction method, etc. of the bill. The bill verification requirement information can include the bill verification process information indicating the bill verification process. The bill verification process refers to the entire process from when the bill is read until the final verification result is output. This process usually includes steps such as reading bill information, parsing bill content, verifying the validity of the bill, and recording logs. The bill verification process information refers to the information describing the specific steps and logic of the bill verification process. The bill verification process information is equivalent to the bill verification logic corresponding to the first bill, which can detail what operations need to be performed during the bill verification process, as well as the order and conditions of these operations. In this way, based on the bill verification process information, logical verification of the bill can be achieved. Logical verification refers to the verification of business processes and rules based on anti-tampering signature verification.

[0114] Among them, the ticket verification requirement information can clarify the functions and requirements to be achieved by ticket verification. Thus, the ticket verification requirement information further includes a verification requirement label, which is used to indicate whether the ticket verification node is a node with logical verification requirements. When the verification requirement label indicates that the ticket verification node is a node without logical verification requirements, the ticket generation node does not need to write the ticket verification logic corresponding to the first ticket into the corresponding ticket; when the verification requirement label indicates that the ticket verification node is a node with logical verification requirements, that is, the ticket verification node needs to strongly verify the logic of the first ticket generated by the upstream ticket generation node, the ticket generation node needs to write the ticket verification logic corresponding to the first ticket into the corresponding ticket. Among them, logical verification requirements refer to a series of verifications and tests on the logic of the system that need to be carried out during the software development and system design processes to ensure that the system or software operates in the expected manner.

[0115] Step 220, generate the first ticket verification execution program code according to the ticket verification process information.

[0116] Among them, the first ticket verification execution program code refers to the executable code form of the ticket verification process information corresponding to the first ticket. Since the ticket verification program execution code has the advantages of being easy to modify and flexible to handle, it can improve the flexibility of ticket processing. When the verification requirement label indicates that the ticket verification node is a node with logical verification requirements, the present disclosure can generate the first ticket verification execution program code according to the ticket verification process information. The first ticket verification execution program code can adopt different programming languages such as JavaScript script, C++, python, etc., and the selected programming language needs to be recognized and executable under the compilers or virtual machines of different backend languages, without specific limitation. In the following embodiments, JavaScript (JS) script is used as an example for illustration. Thus, the ticket generation node of the present disclosure can encapsulate the ticket verification process information (i.e., ticket verification logic and related data) with the JS script based on the ticket verification process information.

[0117] Among them, when the verification requirement label indicates that the ticket verification node is a node without logical verification requirements, the ticket generation node does not need to generate the first ticket verification execution program code, and further generates the first ticket according to the second ticket information, ticket modification information, and ticket signature. The process of generating the first ticket will be described in subsequent embodiments and will not be elaborated here first.

[0118] As Figure 4 shown, it is a schematic diagram of a process for full-link data anti-tampering based on the JS script. Figure 4 It shows that when the verification system 410 (such as a terminal gateway) corresponding to the downstream ticket verification node receives and verifies the tickets transmitted by multiple business logics, the ticket chain can achieve the characteristics of business data anti-tampering, business logic verification, and decoupling of upstream and downstream businesses. Figure 4The service links corresponding to two parallel service logics (i.e., service logic L1 and service logic L2) are shown, which can implement different service functions. Among them, different service module units (i.e., subsystems in the figure, which can be understood as different service requirements) can be included in different service logic links. For example, the operation object generates the structure 430 of ticket A by calling the first subsystem 420 (corresponding to Figure 4 subsystem A in it), and the structure 430 of ticket A includes the field 431 corresponding to key element A and the field 432 corresponding to signature A. At this time, ticket A is the last generated ticket in the ticket chain, equivalent to a first ticket. And since the corresponding verification requirement label indicates that the ticket verification node is a node without logical verification requirements, the structure 430 of ticket A does not contain a JS script. When adding a ticket in the second subsystem 440 (corresponding to Figure 4 subsystem B in it) in the service link corresponding to service logic L1, the corresponding subsystem B can verify the signature of ticket A and generate the structure 450 of ticket B. At this time, ticket B is equivalent to the updated first ticket. And since the corresponding verification requirement label indicates that the ticket verification node is a node without logical verification requirements, the structure 450 of ticket B also does not contain a JS script. When adding a ticket in the third subsystem 460 (corresponding to Figure 4 subsystem C in it) in the service link corresponding to service logic L1, the corresponding subsystem C can verify the signature of ticket B and generate the structure 470 of ticket C. And the structure 470 of ticket C includes the field 471 corresponding to key element C, the field 472 corresponding to signature C, and the field 473 corresponding to JS script C. At this time, ticket C in the ticket chain is equivalent to the updated first ticket. And since the corresponding verification requirement label indicates that the ticket verification node is a node with logical verification requirements, ticket C contains the corresponding generated JS script C. At this time, when the ticket verification node verifies ticket C, in addition to calling the function of the ticket chain SDK to verify the signature C in ticket C, it also needs to verify the logic C in the JS script C. In this way, the service link corresponding to service logic L1 is equivalent to the link after "ticket A - ticket B - ticket C" is linked. Similarly, for subsystem D, subsystem E, and subsystem F in service logic L2, the corresponding tickets D, E, and F can be generated respectively.

[0119] It can be understood that as Figure 4 shown, the "JavaScript script" among them is an optional ticket field, and whether to generate the corresponding ticket verification execution program code can be determined according to the indication information of the verification requirement label. For nodes without logical verification requirements, only the "key element" field that is expected to be obtained by downstream nodes (i.e., ticket verification nodes or nodes corresponding to adding tickets) needs to be passed in. And the ticket chain system itself will ensure the immutability of tickets through cryptographic technology. At this time, the downstream ticket verification party only needs to call the interface function of the ticket chain system to verify the signature to complete the ticket trust verification (asFigure 4 Among the tickets A, B, D, and E). When the downstream node (i.e., the ticket verification node or the node corresponding to the additional ticket) needs to strongly verify the ticket data logic of the upstream node, the upstream node can write the ticket verification logic into the ticket using a JavaScript script. Then, the downstream node can input specific verification parameters on the basis of signature verification to complete the ticket verification logic (such as Figure 4 tickets C and F in).

[0120] It should be noted that the additional ticket of the present disclosure is a new ticket generated on the basis of the existing ticket through the ticket processing method of the present disclosure and linked to the ticket chain. After the first ticket is generated, subsequent tickets are generated by appending. The additional ticket allows dynamic expansion of tickets on the ticket chain, supports operations such as ticket transfer, splitting, and merging, while maintaining the integrity and immutability of the ticket chain. For example, the additional ticket can extend the validity period of the ticket, change the holder, update the usage status, etc.

[0121] In the above embodiment, the present disclosure can generate the corresponding first ticket verification execution program code according to the requirements of each business module unit, rather than relying on the ticket verification logic corresponding to the generation of the first ticket, which improves the flexibility of ticket processing.

[0122] In some embodiments, generating the first ticket verification execution program code according to the ticket verification process information includes:

[0123] Extracting information from the ticket verification process information to obtain ticket verification process interaction information and ticket verification process logic information;

[0124] Generating the first ticket verification execution program code according to the ticket verification process interaction information and the ticket verification process logic information.

[0125] Among them, the ticket verification process interaction information is used to represent the relevant configuration information of the input and output corresponding to the first ticket verification execution program code. The ticket verification process interaction information can clarify the input configuration information corresponding to the first ticket verification execution program code (such as ticket-related information, ticket amount, ticket date, ticket number, etc.) and the output configuration information (such as verification result, prompt information, etc.). The ticket verification process logic information is used to indicate the logic of the ticket verification process, such as reading ticket information, verifying ticket validity, recording logs, exception handling, etc. Further, the present disclosure can use an automated tool (such as a code generator) to generate the first ticket verification execution program code, that is, convert the input ticket verification process interaction information and ticket verification process logic information into specific code implementations.

[0126] In other embodiments, generating the first ticket verification execution program code according to the ticket verification process interaction information and the ticket verification process logic information includes:

[0127] Obtaining code generation prompt words;

[0128] Based on the code generation prompt words, ticket verification process interaction information, and ticket verification process logic information, a preset large language model is called to generate code, and the first ticket verification execution program code is obtained.

[0129] Among them, the present disclosure can also generate the first ticket verification execution program code in the manner of a large language model. Specifically, the ticket generation node can first obtain code generation prompt words, which are used to prompt the preset large language model to generate the first ticket verification execution program code that meets the requirements, and can include code compilation languages, code compilation specifications, etc. By combining natural language to prompt the preset large language model to generate the corresponding first ticket verification execution program code, programming can be made more intuitive and efficient. Moreover, this method of using simple language descriptions to assist the large language model in generating complex code reduces the code generation time and also reduces the possibility of coding errors.

[0130] In some embodiments, when the ticket generation node encapsulates the ticket verification process information with a JS script based on the ticket verification process information, the JS field structure corresponding to the generated first ticket verification execution program code must be in standard JavaScript syntax. In this way, the ticket chain system can pre-compile and pre-execute the first ticket verification execution program code to ensure that the script written into the ticket chain is true and valid.

[0131] Step 230, obtain the ticket modification information, private key data corresponding to the ticket generation node, and the second ticket information corresponding to the second ticket adjacent to the first ticket in the ticket chain.

[0132] Among them, the ticket modification information is used to indicate the key element data obtained by the ticket generation node. The ticket modification information can be the new ticket information obtained by the first node that generates a ticket in the ticket chain, or the additional ticket information obtained by the node that generates an additional ticket in the ticket chain, without limitation.

[0133] Among them, the private key data refers to the data used to generate the ticket signature corresponding to the first ticket. The ticket chain system can create a set of public-private key pairs (including a public key and a private key, authorized and issued by the KMS system) for the ticket generation node, authorize the use permission of the private key data for the ticket generation node, and authorize the public key data corresponding to the above-mentioned ticket generation node for the ticket verification node that verifies the first ticket. In this way, based on the security authorization of the KMS system and the cryptographic cooperation, the present disclosure can implement a tamper-proof ticket verification mechanism.

[0134] Among them, the second ticket is a ticket adjacent to the first ticket, and the second ticket and the first ticket belong to the same ticket chain. The second ticket information is the ticket information corresponding to the second ticket. For example Figure 4As shown, in the bill chain corresponding to the business logic L1, when bill C is the newly generated first bill, the adjacent bill B is the second bill corresponding to bill C, and bill A is the second bill corresponding to bill B. The bill chain of the present disclosure can be constructed based on the data structure of the blockchain to achieve tamper-proof of the full-link data. Moreover, this bill chain belongs to the concrete blockchain concept, and bills belonging to the same bill chain can be linked, thereby enabling full-link logical verification.

[0135] Step 240: Generate a bill signature corresponding to the bill generation node based on the private key data.

[0136] Among them, the bill signature refers to the signature generated by the bill generation node based on the private key data. To ensure the validity and security of the bill, the embodiments of the present disclosure can generate the bill signature corresponding to the node through the public-private key pair in cryptography technology to ensure the tamper-proof of the bill. The bill generation node uses the private key data to sign the first bill to prove that the first bill is initiated by it. At this time, the downstream bill verification node can complete the bill trust verification by calling the interface function of the bill chain system to verify the signature, so as to confirm the authenticity and integrity of the first bill.

[0137] In some embodiments, generating a bill signature corresponding to the bill generation node based on the private key data may include:

[0138] Calculate the digest of the bill modification information according to a preset digest algorithm to obtain a first digest;

[0139] Encrypt the first digest based on the private key data to obtain the bill signature corresponding to the bill generation node.

[0140] Among them, the process of generating the corresponding bill signature includes calculating the digest of the data of the bill generation node using a preset digest algorithm (such as the hash algorithm) to obtain a first digest, and then encrypting the first digest with the private key of the bill generation node. In addition, the difference in the signature algorithm can be reflected in the adoption of different preset digest algorithms, etc.

[0141] In other embodiments, generating a bill signature corresponding to the bill generation node based on the private key data may further include: calculating the digest of at least one of the first bill verification execution program code and the second bill information, and the bill modification information according to a preset digest algorithm to obtain a first digest, and encrypting the first digest based on the private key data to obtain the bill signature corresponding to the bill generation node. In this way, the embodiments of the present disclosure can flexibly select the data for digest calculation according to the signature requirements, which can improve the flexibility and security of signature generation.

[0142] In other embodiments, generating a bill signature corresponding to the bill generation node based on the private key data may further include:

[0143] Obtain the node permission information of the bill generation node;

[0144] Generate a bill signature corresponding to the bill generation node based on the private key data and the node permission information.

[0145] Among them, the node permission information is used to indicate the permission scope of the bill generation node in the bill chain. The node permission information may include the node role of the bill generation node (i.e., different roles correspond to different permissions), the operation scope, the node validity period, etc. When generating the signature, the present disclosure may use the node permission information of the bill generation node as part of the signature to ensure that only nodes or users with specific permissions can generate a valid signature. Specifically, the node permission information and the bill modification information are subjected to digest calculation to obtain a first digest, and the first digest is encrypted based on the private key data to obtain the bill signature corresponding to the bill generation node. In addition, the present disclosure may also perform digest calculation on at least one of the node permission information, the first ticket verification execution program code, and the second bill information, and the bill modification information to obtain a first digest, and encrypt the first digest based on the private key data to obtain the bill signature corresponding to the bill generation node, without limitation. In this way, the generated bill signature not only verifies the integrity of the data but also implies the legality of the permissions.

[0146] In the above embodiments, when generating the bill signature, the present disclosure may consider the node permission information, the first ticket verification execution program code, and the second bill information as needed, improving the flexibility and security of signature generation. And because the bills in the same bill chain are appended into a chain, in this way, by verifying the bill signature of the first bill at the ticket verification node, it is equivalent to verifying the signature of the node that generates the last bill in the current business link, thereby proving the legality of the bill chain.

[0147] Step 250, generate a first bill according to the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0148] Among them, the first bill refers to the bill finally generated in the current bill chain. As Figure 5 shown, it is a schematic diagram of the principle for the bill generation node in the bill chain to generate the first bill. Among them, the bill chain system may create a set of public-private key pairs, which are authorized and issued by the KMS system 510. In this way, the use permission of the private key data 511 (such as the private key A in Figure 5 ) can be authorized for the bill generation node 520 (such as module A in Figure 5 , also called the bill issuing party) in the bill chain, and the public key data 512 of the above signature party (such as the public key in Figure 5 ) can be authorized for the ticket verification node 530 (such as module B in Figure 5The public key in A). Based on the security authorization of the KMS system 510, in one ticket issuance and verification process, module A can use the private key issued by the KMS system to issue tickets. Specifically, the ticket issuer can encapsulate the ticket verification logic and related data in the "ticket verification logic" field of the ticket using JavaScript based on the obtained ticket verification requirement information, and finally pass it to the downstream ticket verifier based on the ticket chain SDK function. At this time, the ticket issuer can generate the structure 540 of ticket A, and at this time, ticket A contains key element A, ticket verification logic A based on the JavaScript script, and signature A. Further, the ticket verifier can also obtain ticket A by calling the ticket chain SDK, verify the signature of ticket A of the ticket issuer using the authorized public key A, and execute the JavaScript script in the ticket, so as to realize the verification of the legality and correctness of the upstream issued ticket. In this way, the ticket processing method provided by the present disclosure does not require additional coupling logic such as reverse lookup, improving the efficiency and flexibility of ticket processing.

[0149] In some embodiments, generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature may include:

[0150] Performing a hash process on the second ticket information to obtain ticket hash data corresponding to the second ticket information;

[0151] Generating the first ticket based on the ticket hash data, the first ticket verification execution program code, the ticket modification information, and the ticket signature.

[0152] Among them, based on the second ticket information, tickets generated by other nodes linked to the first ticket can be obtained. In the ticket structure of the present disclosure, there is a field for storing the hash corresponding to the second ticket information, that is, the PreHash field. At the same time, the hash in the PreHash field can be considered when generating the ticket signature. In this way, by verifying the first ticket, the anti-tampering verification of the previous ticket can be realized. For example, as Figure 6 shown, it is a schematic structural diagram of adding tickets in the ticket chain to form a chain relationship. Among them, in this chain structure, ticket A is the first generated ticket in the ticket chain, and subsequent tickets B to N are additional tickets. A PreHash field can be set in the ticket header of each ticket, which is the hash of all the contents of the previous ticket (that is, the second ticket). At the same time, this field will be signed. In this way, each ticket holds the ticket information hash of the previous node (which can be marked as PreHash, that is, the ticket hash data) to form a ticket chain. And when these tickets are appended into a chain, the signature of the previous node will be verified. In this way, the last ticket verifier in the business link only needs to verify the signature of the last node to prove the legality of the ticket chain. In addition, the first ticket verification execution program code can also be stored in each ticket ( Figure 6Not shown. The ticket structure can be flexibly adjusted according to the existence of the first ticket verification execution program code), ticket modification information (i.e., key elements), and ticket signature.

[0153] It should be noted that, as Figure 6 shown, to ensure the security of the key elements, in the present disclosure, the first ticket is generated based on the ticket hash data, the first ticket verification execution program code, the ticket modification information, and the ticket signature, including: performing a hash process on the ticket modification information to obtain the ticket modification hash data corresponding to the ticket modification information; generating the first ticket based on the ticket hash data, the first ticket verification execution program code, the ticket modification hash data (such as the key element hash as Figure 6 shown) and the ticket signature.

[0154] In the above embodiment, compared with the related art that uses an immutable smart contract to deploy predefined rules, the ticket issuer in the present disclosure can write the corresponding ticket verification logic for the ticket verification requirement information using program code (such as a JavaScript script) and encapsulate it in the "ticket verification logic" field of the ticket. In this way, when the ticket flows to the ticket verifier, the ticket verifier can verify whether the ticket meets all the requirements and conditions by executing these predefined ticket verification logics. In this way, the ticket chain system can achieve a high degree of flexibility and customization. Different ticket verifiers can also set different ticket verification requirement information according to their respective business needs, while the ticket issuer can generate compliant tickets according to these requirements. Thus, the present disclosure can better ensure the accuracy, reliability, and compliance of the tickets, and improve the efficiency and security of ticket processing.

[0155] In some embodiments, generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature includes:

[0156] Performing a pre-execution verification on the first ticket verification execution program code to obtain a code pre-execution verification result;

[0157] When the code pre-execution verification result is verified to pass, generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature.

[0158] Among them, the pre-execution verification result of the code is used to indicate the result after the pre-execution verification of the first ticket verification execution program code. After generating the first ticket verification execution program code, the present disclosure can perform a pre-execution verification on the first ticket verification execution program code attached to the first ticket. When the pre-execution verification result of the code is verified to pass, a first ticket is generated according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature; when the pre-execution verification result of the code is verified to fail, an error prompt message of the first ticket verification execution program code can be returned to prompt the business party using the ticket chain SDK to make corrections.

[0159] Among them, the pre-execution verification of the first ticket verification execution program code can include two stages: pre-execution compilation verification and pre-execution code running verification. The pre-execution compilation verification is equivalent to static checking, that is, detecting whether there are syntax errors in the first ticket verification execution program code through a preset parsing engine (for example, if the first ticket verification execution program code is a JS script, the corresponding JavaScript parsing engine). The pre-execution code running verification is equivalent to dynamic testing, and the first ticket verification execution program code is executed through an embedded preset running engine (for example, if the first ticket verification execution program code is a JS script, the corresponding JavaScript running engine) to ensure that the first ticket verification execution program code will not throw an exception during operation. Based on this, performing a pre-execution verification on the first ticket verification execution program code to obtain the pre-execution verification result of the code can specifically include: performing a pre-execution compilation verification on the first ticket verification execution program code to obtain a pre-execution compilation verification result; when the pre-execution compilation verification result is verified to pass, performing a pre-execution running verification on the first ticket verification execution program code to obtain a pre-execution running verification result. Among them, if the pre-execution running verification result is verified to pass, it is determined that the pre-execution verification result of the first ticket verification execution program code is verified to pass. When the pre-execution compilation verification result is verified to fail or the pre-execution running verification result is verified to fail, it is determined that the pre-execution verification result of the first ticket verification execution program code is verified to fail.

[0160] In the above embodiments, since the first ticket verification execution program code (such as a JavaScript script) is an important part for describing the ticket verification logic, it can ensure that subsequent ticket verifiers can verify the legality and logical correctness of the ticket through the script. Thus, the present disclosure realizes the online verification of dynamic script logic by embedding a JavaScript engine, and on the basis of ensuring the immutability of the ticket and the verification of key elements based on cryptography, it endows the ticket with more flexibility, enabling the business to implement verifiable and tamper-proof business logic based on the ticket. The ticket chain system will pre-compile and pre-execute the JavaScript script to ensure that the script written into the ticket chain is true and valid. This means that before the first ticket verification execution program code is officially used, the system will check its syntax correctness to ensure that there are no runtime errors. In addition, the ticket verification logic method of the present disclosure is not limited, and the generated ticket verification program execution code has the advantages of being easy to modify and flexible to handle, while the smart contract must be set up at the beginning and cannot be modified. When the verification logic needs to be modified, a new smart contract needs to be regenerated. Therefore, the present disclosure can improve the flexibility of ticket processing.

[0161] In some embodiments, generating a first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature includes:

[0162] Generating a ticket based on the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature according to a preset ticket format to obtain a candidate ticket corresponding to the ticket generation node;

[0163] Performing serialization processing on the candidate ticket to obtain the first ticket.

[0164] Wherein, as Figure 6 shown is a preset ticket format provided by the present disclosure, and the specific form of the preset ticket format can also be adjusted as needed without limitation. A candidate ticket refers to a ticket obtained by encapsulating the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature based on the preset ticket format.

[0165] Wherein, serialization refers to converting a complex data structure (such as the block structure of a ticket chain) into a string or other transmissible format for easy transmission over a network. The present disclosure performs serialization processing on the candidate ticket, which can stringify the entire ticket linked in a block structure and directly transmit it to the downstream ticket verification node through a network or other means to complete the entire ticket issuance process. Thus, the present disclosure can improve the efficiency of ticket processing.

[0166] In some embodiments, after generating the first ticket verification execution program code according to the ticket verification process information, the method further includes:

[0167] Obtain the modified information of the ticket verification requirement;

[0168] Update the first ticket verification execution program code according to the modified information of the ticket verification process to obtain the second ticket verification execution program code;

[0169] Update the first ticket according to the second ticket verification execution program code.

[0170] Among them, when the verification requirement corresponding to the first ticket currently generated by the ticket generation node (i.e., the ticket issuing party) changes, the modified information of the ticket verification requirement can be obtained. The modified information of the ticket verification requirement includes the modified information of the ticket verification process indicating the ticket verification process. The modified information of the ticket verification requirement has the same meaning as the above-mentioned ticket verification requirement information, and is used to represent the ticket verification requirement information obtained after the current verification requirement changes. The modified information of the ticket verification process has the same meaning as the above-mentioned ticket verification process information, and is used to represent the ticket verification process information obtained after the current verification requirement changes. Further, the first ticket verification execution program code can be updated according to the modified information of the ticket verification process to obtain the second ticket verification execution program code. The specific form and generation method of the second ticket verification execution program code are the same as those of the above-mentioned first ticket verification execution program code, except that the ticket verification process information it depends on has changed, which will not be elaborated here. Further, referring to step 250, the present disclosure can update the first ticket according to the second ticket verification execution program code, that is, the first ticket can be regenerated according to the second ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature. In this way, the present disclosure can flexibly update the ticket verification execution program code and the ticket corresponding to the ticket generation node, that is, the generated ticket verification program execution code has the advantages of being easy to modify and flexible to process, thereby improving the flexibility of ticket processing.

[0171] In some embodiments, as Figure 7 shown, it is a flowchart of a ticket processing method provided by the present disclosure. This method is applied to a ticket verification node, and this method can be executed by a computer device, which can specifically be a terminal or a server. The ticket processing method can include:

[0172] Step 710, obtain the first ticket to be verified and the public key data corresponding to the ticket generation node that generates the first ticket.

[0173] Among them, the first ticket is the last generated ticket in the ticket chain to be verified, and the specific generation process of the first ticket has been described in detail in the above embodiments and will not be elaborated here. The public key data refers to the data used to verify the ticket signature corresponding to the first ticket. The present disclosure can be authorized by the KMS system and send the public key data corresponding to the ticket generation node to the ticket verification node.

[0174] Step 720, verify the ticket signature corresponding to the first ticket based on the public key data to obtain a verification result.

[0175] Among them, the ticket verification node of the present disclosure can verify the ticket signature in the first ticket through the public key data. By verifying the signature content and the ticket content, the validity of the ticket can be verified, and it can be confirmed whether the ticket has been tampered with. In this way, the present disclosure can ensure the security of keys and authorization authentication by the KMS system, and only authorized nodes are entitled to issue tickets, verify tickets, or append tickets, improving the security of ticket processing.

[0176] In some embodiments, verifying the signature of the ticket signature corresponding to the first ticket based on the public key data to obtain a signature verification result includes:

[0177] Decrypting the ticket signature corresponding to the first ticket based on the public key data to obtain a decryption result;

[0178] Calculating a digest of the ticket modification information according to a preset digest algorithm to obtain a second digest;

[0179] Determining the signature verification result of the ticket signature according to the comparison result between the decryption result and the second digest.

[0180] Among them, the public key data and the private key data corresponding to the ticket generation node in the present disclosure are a pair of keys and are mutually related. The ticket verification node can verify the signature of the ticket signature corresponding to the first ticket based on the public key data to obtain a signature verification result. At this time, the signature verification result can indicate that the ticket signature is verified as qualified or failed. Specifically, the ticket verification node first decrypts the ticket signature corresponding to the first ticket using the public key data to obtain a decryption result, and this decryption result is a digest value. Further, the ticket verification node can calculate the digest of the ticket modification information again according to the same preset digest algorithm (such as a hash algorithm) as the signature process to obtain a second digest. Further, if the decryption result is consistent with the recalculated second digest, it is determined that the signature verification is qualified; if the decryption result is inconsistent with the recalculated second digest, it is determined that the signature verification fails.

[0181] It should be noted that if the data used to generate the first digest in the signature process includes not only the ticket modification information, the second digest is regenerated according to the used data, which will not be elaborated.

[0182] In some embodiments, if the node permission information is also included when generating the ticket signature, the node permission information of the ticket generation node can be obtained, and the first ticket is verified for permissions based on the node permission information. When the result of the permission verification is passed, the signature of the ticket signature corresponding to the first ticket is verified based on the public key data to obtain a signature verification result. In this way, the present disclosure can first verify the permissions of the first ticket based on the node permission information of the ticket generation node to ensure that only nodes with corresponding permissions can perform specific operations, and then verify the ticket signature to prevent unauthorized users from operating or tampering with data, thereby ensuring the security of ticket processing.

[0183] In the above embodiments, the present disclosure can verify the signature of the bill using the public key data of the bill generation node, and can verify the integrity and validity of the generated first bill.

[0184] Step 730, when the signature verification result indicates that the signature verification is qualified, perform bill parsing on the first bill to obtain the first bill verification execution program code corresponding to the first bill and the bill modification information.

[0185] In some embodiments, when serializing the candidate bill to obtain the first bill, during the bill verification process, the bill verification node can first perform a deserialization operation on the received first bill in serialized format (such as a Protobuf format binary sequence) to obtain the candidate bill. Through this process, the system can parse the original bill structure from the serialized data, including the key elements of the first bill (i.e., the bill modification information), the JavaScript script (i.e., the first bill verification execution program code), and the bill signature. Among them, the deserialization is implemented based on the parsing rules defined by the Protobuf protocol, which can ensure the consistency and integrity of the bill data. Further, after successfully parsing the bill, the system will call the public key data issued by the KMS system and verify the bill signature. In this way, by verifying the signature content and the bill content, it can be confirmed whether the first bill has been tampered with.

[0186] Step 740, perform code verification on the first bill verification execution program code according to the bill modification information to obtain a bill verification result.

[0187] Among them, the bill verification result is used to indicate the code verification result of the first bill verification execution program code. When the bill verification result indicates that the first bill verification execution program code passes the code verification, it is determined that the bill verification of the first bill is successful; when the bill verification result indicates that the first bill verification execution program code fails the code verification, it is determined that the bill verification of the first bill fails. Specifically, when the signature verification result indicates that the signature verification is qualified, the code of the first bill verification execution program code can be further verified according to the bill modification information to meet the verification requirements of specific business logics. Subsequently, the bill chain SDK executes the first bill verification execution program code attached to the first bill through the embedded JavaScript engine and receives the returned verification result boolean value. For example, if the returned verification result boolean value is true, it can indicate that the verification is successful, that is, the first bill meets all the rules and conditions defined in the first bill verification execution program code. If the returned verification result boolean value is false, it indicates that the verification fails, that is, the first bill does not meet some of the rules or conditions in the first bill verification execution program code. In this way, through this process, the system can dynamically verify the validity of the bill according to the logic defined by the script. After the script verification is successful, the system completes the entire bill verification process.

[0188] In some embodiments, code verification is performed on the first ticket verification execution program code according to the ticket modification information to obtain a ticket verification result, including:

[0189] Obtain ticket verification data;

[0190] Perform code verification on the first ticket verification execution program code based on the ticket verification data and the ticket modification information to obtain a ticket verification result.

[0191] Among them, the ticket verification data refers to the to-be-verified parameters injected by the ticket verification node into the first ticket verification execution program code (such as a JavaScript script) according to the execution rules of the program code. The to-be-verified parameters refer to the specific data values that need to be checked or verified during the verification process. That is, when the first ticket is passed to the ticket verification node, the ticket verification node can, according to the verification logic corresponding to the first ticket verification execution program code in the first ticket, pass the correct to-be-verified parameters into the verification function of the first ticket verification execution program code (such as the validate function mentioned in the above embodiments). The passed to-be-verified parameters will be used to perform a series of checks to ensure that the ticket complies with all preset verification rules.

[0192] For example, as Figure 8 shown, it is a schematic diagram of the logic verification based on the ticket chain and the JS script provided by the present disclosure. For example, when the ticket generation node creates a ticket and signs it based on the object interaction behavior (such as the consumed resource amount is 100), after accessing the ticket processing service, based on the ticket issuing party 810 (such as Figure 8 module A in), the ticket verification logic is written to generate the structure 820 of ticket A. At this time, the ticket issuing party 810 can create a ticket and sign it based on the ticket verification process information of the ticket generation node, and then the ticket verification party 830 (such as Figure 8 module B in) verifies the ticket content and signature to ensure the integrity and security of the data. At this time, the structure 820 of ticket A contains fields corresponding to script logic A, signature A, and key element A, and the specific meanings of these data have been described in detail in the above embodiments and will not be elaborated here. Specifically, the ticket issuing party 810 can pass parameters by calling the Application Programming Interface (API) to verify the correctness of the script logic in the ticket A. Since the ticket verification party 830 requires the API parameters passed by the ticket issuing party 810 to be equal to 100, the ticket issuing party 810 can generate Figure 8The function validate(target) of script logic A (i.e., the first ticket verification execution program), for example, "function validate(target){return target === 100;}validate(target)". This script logic A defines the JavaScript function validate (i.e., the ticket chain string script parsing interface function), which can represent the value range of target in the parameters that the ticket should guarantee. Among them, when the JavaScript function validate receives a parameter target, it can check whether this parameter is equal to 100. If target is equal to 100, the function returns true, indicating that the verification passes; otherwise, it returns false, indicating that the verification fails. Based on this, the ticket chain system can ensure that the ticket verification logic corresponding to the ticket verification process information is not tampered with. In this way, when the ticket verification node uses the API to call the verification function validate(target), the expected value of the input parameter (i.e., the ticket verification data, such as 100) can be used as the specific parameter corresponding to target. Further, the input parameter is compared with the key elements (i.e., the ticket modification information). Since the transmitted parameter is consistent with the ticket modification information and the logical verification is true, the ticket verification result is that the ticket verification passes. Through the cooperation of the embedded script engine and cryptography, the present disclosure can implement an efficient and tamper-proof ticket verification mechanism.

[0193] In the process of generating the first ticket by the ticket generation node in the ticket chain according to the embodiment of the present disclosure, the ticket verification execution program code can be generated according to the ticket verification process information, and then the ticket verification execution program code is encapsulated in the ticket and sent to the ticket verification node. In this way, the ticket verification node can perform ticket verification based on the ticket verification program execution code. Since the ticket verification program execution code has the advantages of being easy to modify and flexible to process, the flexibility of ticket processing can be achieved.

[0194] Detailed description of the embodiments of the present disclosure in combination with specific application scenarios

[0195] As Figure 9 shown, it is another flowchart of the ticket processing method provided by the present disclosure. In this embodiment, the ticket processing method will be introduced in detail by taking the commodity procurement application scenario as an example and combining the execution entities of each step.

[0196] Step 901, the ticket generation node obtains the ticket verification requirement information.

[0197] Among them, the bill generation node is equivalent to the bill issuer. The bill generation node is the generation node corresponding to the first bill in the bill chain, and the first bill is the last generated bill in the current bill chain. The bill generation node can initiate the bill issuance process through a function call interface, and at this time, the custom function interface name corresponding to the bill issuer can be set to "Issue" to encapsulate fields such as "key elements" and "JavaScript script" into the bill. The ticket verification requirement information includes the ticket verification process information indicating the ticket verification process.

[0198] Step 902, the bill generation node generates the first ticket verification execution program code according to the ticket verification process information.

[0199] Among them, the ticket verification requirement information also includes a verification requirement label, which is used to indicate whether the ticket verification node is a node with logical verification requirements. When the verification requirement label indicates that the ticket verification node is a node without logical verification requirements, the bill generation node does not need to write the ticket verification logic corresponding to the first bill into the corresponding bill, and only needs to pass in the "key elements" field that it hopes the downstream can obtain. The bill chain system itself will ensure the immutability of the bill through cryptographic technology. At this time, the downstream ticket verifier only needs to call the interface function of the bill chain system to verify the signature to complete the ticket trust verification; when the verification requirement label indicates that the ticket verification node is a node with logical verification requirements, that is, when the ticket verification node needs to strongly verify the logic of the first bill generated by the upstream bill generation node, the upstream bill generation node can use JavaScript to write the ticket verification logic (i.e., the first ticket verification execution program code) into the bill. The ticket verifier only needs to pass in specific verification parameters on the basis of the previous signature verification to complete the ticket verification logic verification.

[0200] Step 903, the bill generation node performs a pre-execution check on the first ticket verification execution program code to obtain the code pre-execution check result.

[0201] Among them, the pre-execution verification of the first ticket verification execution program code can include two stages: pre-execution compilation verification and pre-execution code running verification. Based on this, the process of the ticket generation node performing pre-execution verification on the first ticket verification execution program code to obtain the code pre-execution verification result can specifically include: performing pre-execution compilation verification on the first ticket verification execution program code to obtain the pre-execution compilation verification result; when the pre-execution compilation verification result is that the compilation verification passes, performing pre-execution running verification on the first ticket verification execution program code to obtain the pre-execution running verification result. Among them, if the pre-execution running verification result is that the running verification passes, it is determined that the code pre-execution verification result of the first ticket verification execution program code is verification passed. When the pre-execution compilation verification result is that the compilation verification fails or the pre-execution running verification result is that the running verification fails, it is determined that the code pre-execution verification result of the first ticket verification execution program code is verification failed. In this way, online verification of dynamic script logic can be achieved by embedding a JavaScript engine.

[0202] Step 904, when the code pre-execution verification result is verification passed, the ticket generation node obtains the ticket modification information corresponding to the ticket generation node, the private key data, and the second ticket information corresponding to the second ticket adjacent to the first ticket in the ticket chain.

[0203] Among them, the ticket modification information is equivalent to the "key elements" in the generated first ticket. The private key data is used to generate the ticket signature corresponding to the first ticket. The ticket chain of the present disclosure can be constructed based on the blockchain data structure. Therefore, the present disclosure will simultaneously obtain the second ticket information corresponding to the second ticket adjacent to the first ticket, and combine the second ticket information when generating subsequent tickets to achieve full-link data anti-tampering.

[0204] Step 905, the ticket generation node generates the ticket signature corresponding to the ticket generation node based on the private key data.

[0205] Among them, the present disclosure can use the private key data authorized and issued by the KMS system for signature, and can attach the obtained ticket signature to the end of the ticket. In this way, on the basis of ensuring the immutability of the ticket and the verification of key elements based on cryptography, the present disclosure endows the ticket with more flexibility, enabling the business to achieve verifiable and anti-tamperable business logic based on the ticket.

[0206] Step 906, the ticket generation node generates a candidate ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information, and the ticket signature, and performs serialization processing on the candidate ticket to obtain the first ticket.

[0207] Among them, when generating the bill signature, the present disclosure can consider node permission information, the first ticket verification execution program code, and the second bill information as needed, which can improve the flexibility and security of signature generation. Moreover, since the bills in the same bill chain are appended into a chain, thus, by verifying the bill signature of the first bill at the ticket verification node, it is equivalent to verifying the signature of the node that generates the last bill in the current business link, thereby proving the legality of the bill chain.

[0208] In addition, the present disclosure can also perform serialization processing on candidate bills. For example, a bill containing key elements and codes can be serialized into a binary sequence in the Protobuf format. In this way, the entire bill linked in a block structure can be stringified and directly transmitted to the downstream ticket verification node through networks or other means to complete the entire ticket issuance process. In this way, the present disclosure can improve the efficiency of bill processing.

[0209] Step 907, the bill generation node sends the serialized first bill to the ticket verification node.

[0210] Among them, when the present disclosure transmits the serialized first bill to the downstream ticket verification node, the entire ticket issuance process can be completed.

[0211] In the above embodiment, by combining the blockchain chain structure, Protobuf serialization, cryptographic signature verification, and JavaScript script execution, the present disclosure enables the ticket verification node to not only ensure the validity and integrity of the bill, but also verify the correctness of the business logic, thereby improving the applicability of the bill chain technology in complex business scenarios and also enhancing the flexibility of bill processing.

[0212] Step 908, the ticket verification node obtains the first bill to be verified, the public key data corresponding to the bill generation node that generates the first bill, and the bill verification data.

[0213] Among them, the bill verification data refers to the parameters to be verified injected by the ticket verification node into the first ticket verification execution program code (such as a JavaScript script) according to the execution rules of the program code. That is to say, the ticket verification node can obtain the incoming script parameters, that is, the parameters to be verified required for verifying the script logic.

[0214] Step 909, the ticket verification node performs deserialization processing on the first bill to obtain the first ticket verification execution program code corresponding to the first bill and the bill modification information.

[0215] Among them, in the ticket verification process, the deserialization operation can be first performed on the received binary sequence in Protobuf format. Through this process, the system can parse the original ticket structure from the binary data, including the key elements of the ticket, the JavaScript script, and its signature result. The deserialization is implemented relying on the parsing rules defined by the Protobuf protocol to ensure the consistency and integrity of the ticket data.

[0216] Step 910, the ticket verification node verifies the ticket signature corresponding to the first ticket based on the public key data to obtain the verification result.

[0217] Among them, after successfully parsing the ticket, the public key issued by the KMS can be called to verify the ticket signature in the first ticket, and by verifying the signature content and the ticket content, it is confirmed whether the ticket has been tampered with.

[0218] Step 911, when the verification result indicates that the verification is qualified, the ticket verification node performs code verification on the first ticket verification execution program code according to the ticket modification information to obtain the code verification result.

[0219] Among them, when the verification result indicates that the verification is qualified, the code verification of the first ticket verification execution program code can be further performed according to the ticket modification information to meet the specific business logic verification requirements. Subsequently, the ticket chain SDK executes the first ticket verification execution program code attached in the first ticket through the embedded JavaScript engine and receives the returned verification result boolean value. In addition, when the verification result indicates that the verification fails, a prompt message indicating the verification failure can be displayed to prompt the business party using the ticket chain SDK to make corrections.

[0220] Step 912, when the code verification result is passed, the ticket verification node determines that the ticket verification result is successful ticket verification.

[0221] Among them, when the ticket verification result indicates that the first ticket verification execution program code passes the code verification, it can be determined that the ticket verification of the first ticket is successful. When the ticket verification result indicates that the first ticket verification execution program code fails the code verification, it is determined that the ticket verification of the first ticket fails.

[0222] In the above embodiment, the present disclosure generates the corresponding first ticket by combining the ticket verification execution program code corresponding to the ticket generation node, so that the downstream ticket verification node does not need to separately perceive different business logics and data structures, parse the data for processing and then verify, which can effectively solve the problems of strong correlation and high coupling between the cross-business ticket issuance service and the ticket verification logic in the multi-module and long-link ticket verification scenario, thereby effectively reducing the development and operation and maintenance costs of the ticket verification node, and improving the security and usability of the entire ticket verification logic.

[0223] Description of the device and equipment of the embodiments of the present disclosure

[0224] In various specific embodiments of the present disclosure, when it comes to performing relevant processing based on data related to object characteristics such as object attribute information or object permissions, the permission or consent of the object will be obtained first. Moreover, the collection, use, and processing of such data will comply with relevant laws, regulations, and standards. In addition, when the embodiments of the present disclosure need to obtain data related to object characteristics, a separate permission or separate consent of the object will be obtained by means of a pop-up window or jumping to a confirmation page. After clearly obtaining the separate permission or separate consent of the object, the necessary object-related data for the normal operation of the embodiments of the present disclosure will be obtained.

[0225] It can be understood that although the steps in the above-mentioned various flowcharts are sequentially shown according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this embodiment, the execution of these steps has no strict order limit, and these steps can be executed in other orders. Moreover, at least a part of the steps in the above-mentioned flowcharts may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0226] Referring to Figure 10 , Figure 10 FIG. is a schematic structural diagram of a bill processing device provided by an embodiment of the present disclosure, which is applied to a bill generation node corresponding to a first bill in a bill chain. The bill processing device 1000 includes:

[0227] A first acquisition unit 1001, configured to acquire ticket verification requirement information, where the ticket verification requirement information includes ticket verification process information indicating a ticket verification process;

[0228] A code generation unit 1002, configured to generate first ticket verification execution program code according to the ticket verification process information;

[0229] A second acquisition unit 1003, configured to acquire bill modification information corresponding to the bill generation node, private key data, and second bill information corresponding to a second bill adjacent to the first bill in the bill chain;

[0230] A signature generation unit 1004, configured to generate a bill signature corresponding to the bill generation node based on the private key data;

[0231] A bill generation unit 1005, configured to generate a first bill according to the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0232] Optionally, in some embodiments, the code generation unit 1002 includes:

[0233] An information extraction subunit (not shown), configured to extract information from the ticket verification process information to obtain ticket verification process interaction information and ticket verification process logic information;

[0234] A code generation subunit (not shown), configured to generate the first ticket verification execution program code according to the ticket verification process interaction information and the ticket verification process logic information.

[0235] Optionally, in some embodiments, the code generation subunit is specifically configured to:

[0236] Obtain a code generation prompt word;

[0237] Based on the code generation prompt word, the ticket verification process interaction information, and the ticket verification process logic information, call a preset large language model for code generation to obtain the first ticket verification execution program code.

[0238] Optionally, in some embodiments, after generating the first ticket verification execution program code according to the ticket verification process information, the apparatus further includes:

[0239] A fourth acquisition unit (not shown), configured to acquire ticket verification requirement modification information, where the ticket verification requirement modification information includes ticket verification process modification information indicating the ticket verification process;

[0240] A first update unit (not shown), configured to update the first ticket verification execution program code according to the ticket verification process modification information to obtain a second ticket verification execution program code;

[0241] A second update unit (not shown), configured to update the first ticket according to the second ticket verification execution program code.

[0242] Optionally, in some embodiments, the ticket generation unit 1005 is specifically configured to:

[0243] Perform a hash process on the second ticket information to obtain ticket hash data corresponding to the second ticket information;

[0244] Generate a first ticket based on the ticket hash data, the first ticket verification execution program code, the ticket modification information, and the ticket signature.

[0245] Optionally, in some embodiments, the signature generation unit 1004 is specifically configured to:

[0246] Perform a digest calculation on the ticket modification information according to a preset digest algorithm to obtain a first digest;

[0247] Encrypt the first digest based on the private key data to obtain the ticket signature corresponding to the ticket generation node.

[0248] Optionally, in some embodiments, the signature generation unit 1004 is further specifically configured to:

[0249] Obtain the node permission information of the bill generation node;

[0250] Generate a bill signature corresponding to the bill generation node based on the private key data and the node permission information.

[0251] Optionally, in some embodiments, the bill generation unit 1005 is further specifically configured to:

[0252] Perform a pre-execution check on the first ticket verification execution program code to obtain a code pre-execution check result;

[0253] When the code pre-execution check result indicates that the check passes, generate a first bill based on the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature.

[0254] Optionally, in some embodiments, the bill generation unit 1005 is further specifically configured to:

[0255] Generate a candidate bill corresponding to the bill generation node based on the first ticket verification execution program code, the second bill information, the bill modification information, and the bill signature according to a preset bill format;

[0256] Perform serialization processing on the candidate bill to obtain a first bill.

[0257] Refer to Figure 11 , Figure 11 FIG. is a schematic structural diagram of a bill processing device provided in an embodiment of the present disclosure, which is applied to a ticket verification node. The bill processing device 1100 includes:

[0258] A third acquisition unit 1101, configured to acquire a first bill to be verified and public key data corresponding to the bill generation node that generates the first bill, where the first bill is the last generated bill in the bill chain to be verified;

[0259] A signature verification unit 1102, configured to perform signature verification on the bill signature corresponding to the first bill based on the public key data to obtain a signature verification result;

[0260] A bill parsing unit 1103, configured to, when the signature verification result indicates that the signature verification is qualified, perform bill parsing on the first bill to obtain the first ticket verification execution program code and bill modification information corresponding to the first bill;

[0261] A code verification unit 1104, configured to perform code verification on the first ticket verification execution program code according to the bill modification information to obtain a bill verification result.

[0262] Optionally, in some embodiments, the code verification unit 1104 is specifically configured to:

[0263] Obtain bill verification data;

[0264] Perform code verification on the first ticket verification program code based on the bill verification data and the bill modification information to obtain a bill verification result.

[0265] Optionally, in some embodiments, the signature verification unit 1102 is specifically configured to:

[0266] Decrypt the bill signature corresponding to the first bill based on the public key data to obtain a decryption result;

[0267] Calculate a digest of the bill modification information according to a preset digest algorithm to obtain a second digest;

[0268] Determine the signature verification result of the bill signature according to the comparison result between the decryption result and the second digest.

[0269] Refer to Figure 12 , Figure 12 FIG. is a structural block diagram of a part of the terminal 110 for implementing the bill processing method according to an embodiment of the present disclosure. The terminal 110 includes: a radio frequency (RF) circuit 1210, a memory 1215, an input unit 1230, a display unit 1240, a sensor 1250, an audio circuit 1260, a wireless fidelity (WiFi) module 1270, a processor 1280, and a power supply 1290 and other components. Those skilled in the art can understand that Figure 12 The structure of the terminal 110 shown in

[0270] The RF circuit 1210 can be used for receiving and sending information or signals during a call. Specifically, after receiving the downlink information of the base station, it is given to the processor 1280 for processing; in addition, the uplink data designed is sent to the base station.

[0271] The memory 1215 can be used to store software programs and modules. The processor 1280 executes various functional applications and data processing of the terminal by running the software programs and modules stored in the memory 1215.

[0272] The input unit 1230 can be used to receive input digital or character information, and generate key signal inputs related to the settings and function controls of the terminal. Specifically, the input unit 1230 can include a touch panel 1231 and other input devices 1232.

[0273] The display unit 1240 can be used to display the input information or the provided information as well as various menus of the terminal. The display unit 1240 may include a display panel 1241.

[0274] The audio circuit 1260, the speaker 1261, and the microphone 1262 can provide an audio interface.

[0275] In this embodiment, the processor 1280 included in the terminal 110 can execute the bill processing method of the previous embodiment.

[0276] The terminals of the embodiments of the present disclosure include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, intelligent home appliances, vehicle-mounted terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to input methods, intelligent input products, human-computer interaction processing, etc.

[0277] Figure 13 The structural block diagram of a part of the server 140 for implementing the bill processing method of the embodiments of the present disclosure. The server 140 may vary greatly due to configuration or performance differences, and may include one or more central processing units (CPUs) 1322 (for example, one or more processors) and a memory 1332, and one or more storage media 1330 (for example, one or more mass storage devices) for storing application programs 1342 or data 1344. Among them, the memory 1332 and the storage media 1330 can be transient storage or persistent storage. The program stored in the storage media 1330 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server 140. Further, the central processor 1322 can be set to communicate with the storage media 1330 and execute a series of instruction operations in the storage media 1330 on the server 140.

[0278] The server 140 may further include one or more power supplies 1326, one or more wired or wireless network interfaces 1350, one or more input / output interfaces 1358, and / or one or more operating systems 1341, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0279] The processor in the server 140 can be used to execute the bill processing method of the embodiments of the present disclosure.

[0280] The embodiments of the present disclosure also provide a computer-readable storage medium, and the computer-readable storage medium is used to store program codes, and the program codes are used to execute the bill processing methods of the foregoing embodiments.

[0281] Embodiments of the present disclosure also provide a computer program product, which includes a computer program. The processor of the computer device reads and executes the computer program, so that the computer device implements the above-mentioned bill processing method.

[0282] Terms such as "first", "second", "third", "fourth", etc. (if any) in the specification of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "include" and "comprise" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units does not have to be limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products or devices.

[0283] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Among them, A and B can be singular or plural. The character " / " generally means that the associated objects before and after are in an "or" relationship. "At least one (one) of the following" or a similar expression means any combination of these items, including any combination of single item (one) or plural items (ones). For example, at least one (one) of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0284] It should be understood that in the description of the embodiments of the present disclosure, the meaning of "a plurality (or multiple items)" is more than two. Understandings such as greater than, less than, exceeding, etc. do not include the present number, and understandings such as above, below, within, etc. include the present number.

[0285] In several embodiments provided by the present disclosure, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of units is only a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of devices or units can be in an electrical, mechanical or other form.

[0286] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0287] In addition, the functional units in various embodiments of the present disclosure may be integrated in a processing unit, may exist separately as individual physical units, or two or more units may be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0288] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present disclosure. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs that can store program codes.

[0289] It should also be understood that the various embodiments provided in the present disclosure can be combined arbitrarily to achieve different technical effects.

[0290] The above is a specific description of the embodiments of the present disclosure, but the present disclosure is not limited to the above embodiments. Those skilled in the art can also make various equivalent deformations or substitutions without departing from the spirit of the present disclosure, and these equivalent deformations or substitutions are all included within the scope defined by the claims of the present disclosure.

Claims

1. A bill processing method, characterized in that: The method is applied to a bill generation node corresponding to a first bill in a bill chain, where the first bill is the last bill generated in the bill chain, and the method includes: Acquiring ticket verification requirement information, wherein the ticket verification requirement information includes ticket verification process information indicating a ticket verification process; Generate a first ticket verification execution program code according to the ticket verification process information; Obtaining the bill modification information, private key data corresponding to the bill generation node, and second bill information corresponding to a second bill adjacent to the first bill in the bill chain; Generate a ticket signature corresponding to the ticket generation node based on the private key data; The first ticket is generated according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature.

2. The method according to claim 1, characterized in that: The step of generating a first ticket verification execution program code according to the ticket verification process information includes: Extracting information from the ticket verification process information to obtain ticket verification process interaction information and ticket verification process logic information; A first ticket verification execution program code is generated according to the ticket verification process interaction information and the ticket verification process logic information.

3. The method according to claim 2, characterized in that The step of generating a first ticket verification execution program code according to the ticket verification process interaction information and the ticket verification process logic information includes: Get code generation hint words; Based on the code generation prompt word, the ticket verification process interaction information and the ticket verification process logic information, a preset large language model is called to generate code to obtain a first ticket verification execution program code.

4. The method according to claim 1, characterized in that After generating the first ticket verification execution program code according to the ticket verification process information, the method further includes: Acquire ticket verification requirement modification information, wherein the ticket verification requirement modification information includes ticket verification process modification information indicating a ticket verification process; The first ticket verification execution program code is updated according to the ticket verification process modification information to obtain a second ticket verification execution program code; The first ticket is updated according to the second ticket verification execution program code.

5. The method according to claim 1, characterized in that The step of generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature includes: Performing hash processing on the second ticket information to obtain ticket hash data corresponding to the second ticket information; The first ticket is generated based on the ticket hash data, the first ticket verification execution program code, the ticket modification information and the ticket signature.

6. The method according to claim 1, characterized in that The step of generating a ticket signature corresponding to the ticket generation node based on the private key data includes: Performing digest calculation on the bill modification information according to a preset digest algorithm to obtain a first digest; The first summary is encrypted based on the private key data to obtain a bill signature corresponding to the bill generation node.

7. The method according to claim 1, characterized in that The step of generating a ticket signature corresponding to the ticket generation node based on the private key data includes: Obtaining node authority information of the ticket generation node; A ticket signature corresponding to the ticket generation node is generated based on the private key data and the node authority information.

8. The method according to claim 1, characterized in that: The step of generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature includes: Performing a pre-execution check on the first ticket verification execution program code to obtain a code pre-execution check result; When the code pre-execution verification result is verification passed, the first ticket is generated according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature.

9. The method according to claim 1, characterized in that: The step of generating the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature includes: Based on a preset ticket format, the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature are used to generate a ticket, and a candidate ticket corresponding to the ticket generation node is obtained; The candidate bills are serialized to obtain a first bill.

10. A bill processing method, characterized in that: The method is applied to a vote verification node, and the method comprises: Obtaining a first note to be verified and public key data corresponding to a note generation node that generates the first note, wherein the first note is the last note generated in the note chain to be verified; Verifying the bill signature corresponding to the first bill based on the public key data to obtain a verification result; When the signature verification result indicates that the signature verification is qualified, the first bill is parsed to obtain a first bill verification execution program code and bill modification information corresponding to the first bill; The first ticket verification execution program code is code-verified according to the ticket modification information to obtain a ticket verification result.

11. The method according to claim 10, characterized in that The performing code verification on the first ticket verification execution program code according to the ticket modification information to obtain the ticket verification result includes: Get ticket verification data; The first ticket verification execution program code is code-verified based on the ticket verification data and the ticket modification information to obtain a ticket verification result.

12. The method according to claim 10, characterized in that The verifying the bill signature corresponding to the first bill based on the public key data to obtain a verification result includes: Decrypting the bill signature corresponding to the first bill based on the public key data to obtain a decryption result; Performing digest calculation on the bill modification information according to a preset digest algorithm to obtain a second digest; The verification result of the bill signature is determined according to the comparison result of the decryption result and the second summary.

13. A bill processing device, characterized in that: The device is applied to a bill generation node corresponding to a first bill in a bill chain, wherein the first bill is the last bill generated in the bill chain, and the device comprises: A first acquisition unit, configured to acquire ticket verification requirement information, wherein the ticket verification requirement information includes ticket verification process information indicating a ticket verification process; A code generating unit, used to generate a first ticket verification execution program code according to the ticket verification process information; A second acquisition unit, configured to acquire the bill modification information and private key data corresponding to the bill generation node and second bill information corresponding to a second bill adjacent to the first bill in the bill chain; A signature generation unit, configured to generate a bill signature corresponding to the bill generation node based on the private key data; A ticket generating unit is used to generate the first ticket according to the first ticket verification execution program code, the second ticket information, the ticket modification information and the ticket signature.

14. A bill processing device, characterized in that: The device is applied to a vote verification node, and comprises: A third acquisition unit is used to acquire a first bill to be verified and public key data corresponding to a bill generation node that generates the first bill, wherein the first bill is the last bill generated in the bill chain to be verified; A signature verification unit, configured to verify the bill signature corresponding to the first bill based on the public key data to obtain a verification result; a bill parsing unit, configured to, when the signature verification result indicates that the signature verification is qualified, perform bill parsing on the first bill to obtain a first bill verification execution program code and bill modification information corresponding to the first bill; A code verification unit is used to perform code verification on the first ticket verification execution program code according to the ticket modification information to obtain a ticket verification result.

15. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the bill processing method according to any one of claims 1 to 12 is implemented.

16. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the bill processing method according to any one of claims 1 to 12 is implemented.

17. A computer program product, comprising a computer program, wherein the computer program is read and executed by a processor of a computer device, so that the computer device executes the bill processing method according to any one of claims 1 to 12.

Images