Transaction uplink processing method, related device and medium

Abstract

The invention provides a transaction uplink processing method, a related device and a medium. The method comprises the following steps: acquiring object identity information, Merkel tree proof of a to-be-linked transaction associated bill on a bill Merkel tree, and a generated bill after execution of a to-be-linked transaction; the object identity information, the Merkel tree proof and the generated bill are verified, and after verification succeeds, zero-knowledge proof is generated based on the object identity information, the Merkel tree proof and the generated bill through a zero-knowledge circuit; and sending the zero-knowledge proof to a consensus node, so that the consensus node allocates an invalid mark to the transaction associated bill to be linked after the zero-knowledge proof is successfully verified, and adds a generated bill on a bill Merkel tree. According to the invention, a safe uplink solution with high universality can be provided. The method and the device can be applied to various scenes such as block chains, artificial intelligence and cloud technologies.

Description

Technical Field

[0001] The present disclosure relates to the field of blockchain technology, and in particular to a transaction on-chain processing method, related devices and media. Background Art

[0002] When using blockchain to record transactions, it is difficult to ensure security because the data on the chain is open and transparent. In order to ensure the security of blockchain-recorded transactions, secure computing capabilities are often used to assist, but they are not universal. Secure computing in blockchain lacks guarantees for reliable data sources and traceability of results. There is no standard way to securely upload data to blockchain. There is a lack of a blockchain secure upload solution that is highly universal and secure. Summary of the invention

[0003] The disclosed embodiments provide a transaction on-chain processing method, related devices and media, which can provide a highly versatile and secure on-chain solution.

[0004] According to one aspect of the present disclosure, a transaction on-chain processing method is provided, the transaction on-chain processing method comprising:

[0005] Obtain the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed;

[0006] Verifying the object identity information, the Merkle tree proof, and the generated note, and generating a zero-knowledge proof based on the object identity information, the Merkle tree proof, and the generated note through a zero-knowledge circuit after the verification is successful;

[0007] The zero-knowledge proof is sent to a consensus node so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

[0008] According to one aspect of the present disclosure, a transaction on-chain processing device is provided, the transaction on-chain processing device comprising:

[0009] An acquisition unit, used to acquire object identity information, a Merkle tree certificate of the bill associated with the transaction to be on-chain on the bill Merkle tree, and a generated bill after the transaction to be on-chain is executed;

[0010] A generating unit, configured to verify the object identity information, the Merkle tree proof and the generated note, and generate a zero-knowledge proof based on the object identity information, the Merkle tree proof and the generated note through a zero-knowledge circuit after the verification is successful;

[0011] A sending unit is used to send the zero-knowledge proof to a consensus node, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

[0012] Optionally, the sending unit is specifically configured to:

[0013] Add the invalid flag assigned to the ticket associated with the transaction to be on-chain to the target contract;

[0014] Searching for the bill Merkle tree in the target contract;

[0015] At the bottom layer of the found bill Merkle tree, add the generated bill.

[0016] Optionally, the object identity information includes an object private key;

[0017] The transaction on-chain processing device further includes an on-chain unit, and the on-chain unit is used for:

[0018] The first event that the bill associated with the transaction to be put on the chain is invalid is encrypted with the object public key corresponding to the object private key, and recorded on the blockchain;

[0019] The generated note is encrypted with the object public key and recorded on the blockchain.

[0020] Optionally, the transaction-associated note to be on-chain corresponds to an original resource, and the transaction to be on-chain is a resource transfer transaction for transferring a target resource from the original resource; the generated note includes a first note and a second note, the first note corresponds to the target resource, and the second note corresponds to a difference resource between the original resource and the target resource;

[0021] The step of adding the generated bill to the lowest level of the bill Merkle tree found includes:

[0022] generating the first bill based on the target resource, and generating the second bill based on the difference resource;

[0023] At the bottom layer of the found bill Merkle tree, add the first bill and the second bill.

[0024] Optionally, the generating unit further includes:

[0025] A first verification unit, configured to perform a first verification based on the object identity information and the ticket associated with the transaction to be on-chain;

[0026] A second verification unit, configured to perform a second verification on the transaction-associated note to be on-chain based on the Merkle tree proof if it is determined that the first verification is passed;

[0027] A third verification unit, configured to, if it is determined that the second verification is passed, perform a third verification on the invalidation mark assigned to the ticket associated with the transaction to be on-chain;

[0028] A fourth verification unit, configured to perform a fourth verification on the generated bill if it is determined that the third verification passes;

[0029] A determining unit is configured to determine that the verification is successful if it is determined that the fourth verification passes.

[0030] Optionally, the first verification unit is specifically used to:

[0031] Performing a digest operation on the object private key in the object identity information to obtain an object digest value;

[0032] If the object summary value is consistent with the transaction-associated ticket to be on-chained, it is determined that the first verification is passed;

[0033] If the object summary value is inconsistent with the transaction-associated ticket to be on-chained, it is determined that the first verification fails.

[0034] Optionally, the Merkle tree proof includes a bypass note index of the note associated with the transaction to be on-chain in the note Merkle tree, and a bypass note summary value;

[0035] The second verification unit is specifically used for:

[0036] Determine the bill summary value of the bill associated with the transaction to be on-chain in the bill Merkle tree;

[0037] Calculate the to-be-verified root node digest of the bill Merkle tree based on the bill digest value, the bypass bill index, and the bypass bill digest value;

[0038] If it is determined that the to-be-verified root node digest is consistent with the public root node digest, then it is determined that the second verification is passed;

[0039] If it is determined that the to-be-verified root node digest is inconsistent with the public root node digest, it is determined that the second verification fails.

[0040] Optionally, the third verification unit is specifically used to:

[0041] For the transaction-associated ticket to be put on the chain, based on the object identity information and the Merkle tree proof, generate a target invalidation mark for the transaction-associated ticket to be put on the chain;

[0042] If it is determined that the target invalid mark is consistent with the invalid mark, then it is determined that the third verification is passed;

[0043] If it is determined that the target invalidation flag and the invalidation flag are inconsistent, it is determined that the third verification fails.

[0044] Optionally, the target invalid flag is generated in the following manner:

[0045] Extracting the bypass note index of the note associated with the transaction to be on-chain from the Merkle tree proof;

[0046] Concatenate the object private key in the object identity information and the bypass ticket index to obtain a concatenation result;

[0047] A digest operation is performed on the concatenation result to obtain the target invalidation mark.

[0048] Optionally, the generated note includes a plurality of sub-notes;

[0049] The fourth verification unit is specifically used for:

[0050] Integrate the resources indicated by the plurality of sub-tickets to obtain a first resource;

[0051] If it is determined that the first resource is consistent with the second resource indicated by the transaction-associated ticket to be on-chained, then it is determined that the fourth verification is passed;

[0052] If it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification fails.

[0053] Optionally, the fourth verification unit is specifically used to:

[0054] Obtaining the blockchain address associated with the generated bill;

[0055] Performing address verification on the blockchain address;

[0056] If it is determined that the blockchain address verification is passed, then it is determined that the fourth verification is passed.

[0057] Optionally, the fourth verification unit is specifically used to:

[0058] Determine a first resource amount associated with the generated ticket and a second resource amount associated with the ticket associated with the transaction to be uploaded to the chain;

[0059] If it is determined that the first resource amount is less than or equal to the second resource amount, it is determined that the fourth verification is passed.

[0060] Optionally, the acquisition unit is used to:

[0061] Display the first content page;

[0062] In response to a selection operation on the zero-knowledge circuit execution module in the first content page, displaying a second content page;

[0063] In response to an input operation on the second content page, the object identity information, the Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed are obtained.

[0064] Optionally, the transaction on-chain processing device further includes a first processing unit, and the first processing unit is used to:

[0065] In response to a selection operation on a resource transfer module in the first content page, displaying a third content page;

[0066] In response to a zero-knowledge proof input operation in the third content page, determining a zero-knowledge proof for resource transfer;

[0067] In response to the resource transfer operation in the third content page, a resource transfer transaction is executed based on the zero-knowledge proof, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated ticket of the resource transfer transaction and adds a generated ticket to the ticket Merkle tree.

[0068] Optionally, the transaction on-chain processing device further includes a second processing unit, and the second processing unit is used to:

[0069] In response to a selection operation on a resource transfer module in the first content page, displaying a third content page;

[0070] In response to a zero-knowledge proof input operation in the third content page, determining a zero-knowledge proof for resource extraction;

[0071] In response to a resource extraction operation in the third content page, a resource extraction transaction is performed based on the zero-knowledge proof, so that the consensus node assigns an invalidation mark to an associated ticket of the resource extraction transaction after the zero-knowledge proof is successfully verified.

[0072] Optionally, the transaction on-chain processing device further includes a third processing unit, and the third processing unit is used to:

[0073] In response to a selection operation on a resource access module in the first content page, displaying a fourth content page;

[0074] In response to the resource deposit operation in the fourth content page, a new ticket is generated, and the new ticket is added to the bottom layer of the ticket Merkle tree.

[0075] According to one aspect of the present disclosure, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor implements the transaction on-chain processing method as described above when executing the computer program.

[0076] According to one aspect of the present disclosure, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the transaction on-chain processing method as described above is implemented.

[0077] According to one aspect of the present disclosure, a computer program product is provided, which 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 transaction on-chain processing method as described above.

[0078] The disclosed embodiment takes into account that it is unsafe to directly record the resource pool information after the execution of the transaction to be chained on the blockchain. Transactions related to the same resource pool affect each other, and it is easy to infer the impact of the transaction to be chained on the resource pool from the execution results of other transactions in the same resource pool. Therefore, the disclosed embodiment records the transaction as an associated bill. The execution of the transaction is regarded as the process of splitting the associated bill into the generated bill. The bill itself is isolated and the impact on the resource pool cannot be inferred. The disclosed embodiment obtains the object identity information, the Merkle tree proof of the associated bill of the transaction to be chained on the bill Merkle tree, and the generated bill after the transaction to be chained is executed, and verifies it, and after the verification is successful, a zero-knowledge proof is generated through a zero-knowledge circuit and sent to the consensus node. The characteristic of the zero-knowledge proof is that it can still perform security verification before chaining without leaking the personalized information of the object. After the verification is successful, since the disclosed embodiment adopts a bill-based recording method, an invalid mark is assigned to the associated bill of the transaction to be chained, and a generated bill is added to the bottom layer of the bill Merkle tree. Through the zero-knowledge proof, the verification is completed without leaking personalized information. By recording the bill instead of the resource pool, the security of the on-chain records is improved. The above process can be applied to most transactions to be on-chain and is universal.

[0079] Other features and advantages of the present disclosure will be described in the following description, and partly become apparent from the description, or understood by practicing the present disclosure. The purpose and other advantages of the present disclosure can be realized and obtained by the structures particularly pointed out in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] The accompanying drawings are used to provide further understanding of the technical solution 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 solution of the present disclosure and do not constitute a limitation on the technical solution of the present disclosure.

[0081] Figure 1 It is a schematic diagram of the system architecture of a blockchain network to which an embodiment of the present disclosure is applied;

[0082] Figure 2 It is a schematic diagram of applying the transaction on-chain processing method according to an embodiment of the present disclosure to an electronic invoice scenario;

[0083] Figure 3 is a flowchart of a transaction on-chain processing method according to an embodiment of the present disclosure;

[0084] Figure 4A-4B is a schematic diagram of an implementation process of generating a transaction-related ticket according to an embodiment of the present disclosure;

[0085] Figure 5 is a flow chart of generating a bill Merkle tree according to an embodiment of the present disclosure;

[0086] Figure 6 is a schematic diagram of an implementation process of generating a bill Merkle tree according to an embodiment of the present disclosure;

[0087] Figure 7 is a flow chart for verifying object identity information, Merkle tree proof, and generating a ticket according to one embodiment of the present disclosure;

[0088] Figure 8 is a flow chart of performing a first verification of the identity information of an object according to an embodiment of the present disclosure;

[0089] Fig. 9 is a flow chart of performing a second verification of a Merkle tree proof according to an embodiment of the present disclosure;

[0090] Fig.10 is a schematic diagram of an implementation process of performing a second verification on a Merkle tree proof according to an embodiment of the present disclosure;

[0091] Fig.11 is a flowchart of performing a third verification on an invalid mark according to an embodiment of the present disclosure;

[0092] Fig.12 is a flowchart of generating a target invalidation mark according to an embodiment of the present disclosure;

[0093] Fig.13 is a flow chart of performing a fourth verification of a generated note according to an embodiment of the present disclosure;

[0094] Fig.14 is a flow chart of performing a fourth verification on a generated note according to another embodiment of the present disclosure;

[0095] Fig.15is a flow chart of performing a fourth verification on a generated note according to another embodiment of the present disclosure;

[0096] Fig.16 is a schematic diagram of an implementation process of verification based on a zero-knowledge circuit according to another embodiment of the present disclosure;

[0097] Fig.17 is a flowchart of allocating invalidation marks and increasing generation tickets according to an embodiment of the present disclosure;

[0098] Figure 18A-18B It is a schematic diagram of the implementation process of allocating invalid marks and adding generated tickets according to an embodiment of the present disclosure;

[0099] Fig.19 is a flow chart of adding a generated bill to a found bill Merkle tree according to an embodiment of the present disclosure;

[0100] Figure 20A-20B It is a schematic diagram of the implementation process of adding a generated bill to a found bill Merkle tree according to an embodiment of the present disclosure;

[0101] Fig.21 is a flow chart of chaining the generation of a ticket and the invalidation of the first event according to one embodiment of the present disclosure;

[0102] Fig. 22 is a schematic diagram of the data structure of a first content page on a target terminal according to an embodiment of the present disclosure;

[0103] Fig.23 is a flow chart of obtaining object identity information, Merkle tree proof, and generating a ticket according to an embodiment of the present disclosure;

[0104] Figure 24A-24B is a schematic diagram of an implementation process of obtaining object identity information, Merkle tree proof, and generating a bill according to an embodiment of the present disclosure;

[0105] Fig.25 is a flow chart of performing resource transfer operations according to one embodiment of the present disclosure;

[0106] Figure 26A-26B is a schematic diagram of an implementation process of performing a resource transfer operation according to an embodiment of the present disclosure;

[0107] Fig. 27 is a flow chart of performing a resource extraction operation according to one embodiment of the present disclosure;

[0108] Figure 28A-28B is a schematic diagram of an implementation process of performing a resource extraction operation according to an embodiment of the present disclosure;

[0109] Fig.29 is a flow chart of performing a resource deposit operation according to an embodiment of the present disclosure;

[0110] Figure 30A-Figure 30B is a schematic diagram of an implementation process of executing a resource storage operation according to an embodiment of the present disclosure;

[0111] Figure 31A-Figure 31B It is a detailed diagram of the implementation of a transaction on-chain processing method according to an embodiment of the present disclosure;

[0112] Fig.32 is a module diagram of a transaction on-chain processing device according to an embodiment of the present disclosure;

[0113] Fig.33 It is a terminal structure diagram of a transaction on-chain processing method according to an embodiment of the present disclosure;

[0114] Fig.34 It is a server structure diagram of the transaction on-chain processing method according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0115] In order to make the purpose, technical solution and advantages of the present disclosure more clear, the present disclosure is further described in detail below in conjunction with 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.

[0116] Before further describing the embodiments of the present disclosure in detail, 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 subject to the following interpretations:

[0117] Artificial Intelligence (AI) 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 the best results. In other words, artificial intelligence is a comprehensive technology in computer science that attempts to understand the essence of intelligence and produce a new intelligent machine that can respond in a similar way to human intelligence. Artificial intelligence is to study the design principles and implementation methods of various intelligent machines so that machines have the functions of perception, reasoning and decision-making. Artificial intelligence technology is a comprehensive discipline that covers a wide range of fields, including both hardware-level technology and software-level technology. The basic technologies of artificial intelligence generally include sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, pre-trained model technology, operation / interaction system, mechatronics, etc. Among them, the pre-trained model is also called the large model or basic model. After fine-tuning, it can be widely used in downstream tasks in various major directions of artificial intelligence. Artificial intelligence software technology mainly includes computer vision technology, speech processing technology, natural language processing technology, and machine learning / deep learning. With the research and advancement of artificial intelligence technology, artificial intelligence technology has been studied and applied in many fields, such as common smart homes, smart wearable devices, virtual assistants, smart speakers, smart marketing, unmanned driving, automatic driving, drones, robots, smart medical care, smart customer service, etc. I believe that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0118] Blockchain: Blockchain is a new application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanism, encryption algorithm, etc. Blockchain is essentially a decentralized database, a string of data blocks generated by cryptographic methods. Each data block contains a batch of transaction information, which is used to verify the validity of its information (anti-counterfeiting) and associate with the previous block.

[0119] When using blockchain to record transactions, it is difficult to ensure security because the data on the chain is open and transparent. In order to ensure the security of blockchain-recorded transactions, secure computing capabilities are often used to assist, but they are not universal. Secure computing in blockchain lacks guarantees for reliable data sources and traceability of results. There is no standard way to securely upload data to blockchain. There is a lack of a blockchain secure upload solution that is highly universal and secure.

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

[0121] See also Figure 1The blockchain network shown in the figure includes a witness network and a consensus network. The consensus network refers to the network that uploads the transactions to be uploaded to the blockchain after consensus is reached, and it includes multiple consensus nodes. The witness network refers to the network that generates transactions to be uploaded, does not upload them to the blockchain, but witnesses the upload of the transactions to be uploaded to the blockchain, and it includes multiple witness nodes. The consensus node is the blockchain node.

[0122] Witness nodes do not need to participate in the consensus on the chain. They are mainly used to generate transactions to be chained and witness the chaining of transactions to be chained. Consensus nodes are generally full nodes. Full nodes refer to nodes that maintain all the data of each block on the blockchain. Since consensus nodes need to generate blocks for chained transactions and then chain them, they must of course maintain the data of all blocks on the entire blockchain. Witness nodes are generally light nodes. Light nodes refer to nodes that maintain partial data of each block on the blockchain. For example, after the full node completes the chaining, it only sends the block header of the chained block to the light node. When the light node needs to verify whether it is correctly chained, it uses the summary value in the block header to perform Merkle tree verification.

[0123] The consensus node or blockchain node can be a server in the blockchain network or a user terminal connected to the blockchain network. The specific form of the consensus node or blockchain node is not limited here. It can also be understood that Figure 1 The witness network and consensus network shown can be in different network environments. For example, generally speaking, the witness node is deployed in the witness network in the public network, while the consensus node running the blockchain consensus protocol is deployed in the consensus network in the private network. The witness node and the consensus node can interact through the routing node, and the witness node and the consensus node can also directly transmit data without going through the routing node. It should be noted that since the consensus network is in a relatively secure private cloud, its mutual access is guaranteed by the consensus mechanism, and no additional identity management and network control are required. The witness node is in the public network and may be accessed by other uncertain network terminals. Therefore, the behavior of the witness node and other possible nodes accessing the consensus network needs to be strictly controlled.

[0124] The embodiments of the present disclosure can be applied in various scenarios, such as Figure 2 The scenario of the tax electronic invoice blockchain system shown, etc.

[0125] See also Figure 2 ,The tax electronic invoice blockchain system includes the business layer, the routing agent layer, and the consensus network layer.

[0126] The business layer is the witness network, which includes at least one witness node. The business layer can receive local transaction requests from the electronic tax bureau, enterprises or consumers, such as the electronic tax bureau's electronic invoice issuance transaction chain request, the enterprise's electronic invoice collection transaction chain request, and the consumer's electronic invoice billing chain request. The business layer includes the local tax bureau's server in the tax-specific network, the invoicing server in the public cloud (a server for electronic invoice invoicing of non-critical enterprises), the reimbursement server (a server for electronic invoice reimbursement of non-critical enterprises), the key enterprise server (a server for various electronic invoice transactions of key enterprises), the payment server in the private cloud (a server for invoice-related transactions of consumers in the payment process of non-critical enterprises), the circulation server (a server for invoice-related transactions of goods in the circulation process of non-critical enterprises), and the key enterprise server (a server for invoice-related transactions of consumers in key enterprises). Key enterprises refer to enterprises with a certain scale that require dedicated servers to provide them with invoice-related transactions.

[0127] The server of the local tax bureau in the tax-dedicated network generates an electronic invoice issuance transaction in response to the electronic tax bureau's electronic invoice issuance needs, and requests the consensus network layer to put the transaction on the chain. The invoicing server in the public cloud generates an electronic invoice collection transaction in response to the needs of non-critical enterprises to apply for electronic invoices, and requests the consensus network layer to put the transaction on the chain. The reimbursement server in the public cloud generates an electronic invoice reimbursement transaction in response to the needs of non-critical enterprises to reimburse electronic invoices, and requests the consensus network layer to put the transaction on the chain. The key enterprise server in the public cloud generates an electronic invoice collection or reimbursement transaction in response to the needs of key enterprises to collect or reimburse electronic invoices, and requests the consensus network layer to put the transaction on the chain. The payment server in the private cloud generates a transaction requesting the issuance of an electronic invoice in response to the payment actions of consumers in non-critical enterprises, and requests the consensus network layer to put the transaction on the chain. The circulation server in the private cloud generates an electronic invoice circulation transaction based on the needs of consumers of non-critical enterprises to exchange items, and requests the consensus network layer to put the transaction on the chain. The key enterprise server in the private cloud generates transactions requiring invoicing or circulation based on the payment or item circulation requirements of the key enterprise's consumers, and requests the consensus network layer to upload the transaction to the chain.

[0128] The routing proxy layer refers to the layer that plays a routing role between nodes. It is used for routing data related to the business layer and the consensus network layer. It includes authentication services, certificate caches, routing services, and peer-to-peer services. The routing service is used to route transactions to be uploaded to the consensus network layer. The authentication service is used to authenticate transactions to be uploaded before routing them to the consensus network layer, such as verifying the signature of the transaction to be uploaded based on the key certificate. The certificate cache is specifically used to cache the public and private key certificates required in the authentication service. The peer-to-peer service provides peer-to-peer communication between nodes. After the transaction to be uploaded is uploaded to the consensus network layer, the receipt of the on-chain verification information returned by the consensus network layer is carried out through the peer-to-peer service.

[0129] The consensus network layer includes a consensus network and a privacy blockchain network. The consensus network includes multiple first consensus nodes, each of which contains a permission contract for determining whether it has the permission to go on the chain, a storage device used in the transaction blockchain on-chain processing, and locally maintains its own on-chain blocks. The privacy blockchain network includes multiple second consensus nodes, each of which contains a permission contract for determining whether it has the permission to go on the chain, a storage device used in the privacy transaction blockchain on-chain processing, and locally maintains its own on-chain blocks.

[0130] Figure 2In the consensus network layer, there are three branches. If a request for the issuance of electronic invoices generated by the local tax bureau server is forwarded by the proxy node, it is forwarded to the first consensus node of branch 1. The first consensus node queries its own permission contract and finds that it does not have the permission to be on the local transaction blockchain (because the issuance of electronic invoices is a private matter and must be transferred to the privacy blockchain network to be linked to the privacy blockchain), so it forwards the request to the second consensus node in branch 1. If a request for the issuance of electronic invoices, reimbursement and other transactions generated by various servers of the public cloud is forwarded by the proxy node, it is forwarded to the first consensus node of branch 2. The first consensus node queries its own permission contract and finds that it does not have the permission to record accounts on the local transaction blockchain (because the issuance and reimbursement of electronic invoices are private matters and must be transferred to the privacy blockchain network to be linked to the privacy blockchain), so it forwards the request to the second consensus node in branch 2. If a request for the issuance of electronic invoices, the circulation of electronic invoices and other transactions generated by various servers of the private cloud are forwarded by the proxy node, it is forwarded to the first consensus node in branch 3. The first consensus node queries its own permission contract and finds that it does not have the permission to record accounts on the local transaction blockchain (because the issuance and circulation of electronic invoices are private matters that must be transferred to the privacy blockchain network and linked to the privacy blockchain), so it forwards the request to the second consensus node in branch 3. After the second consensus node of branch 1-3 records the private transaction on the private transaction blockchain, the private transaction blockchain is not accessible to the outside world, which improves the security of the private transaction on-chain.

[0131] General description of the disclosed embodiments

[0132] According to an embodiment of the present disclosure, a transaction on-chain processing method is provided.

[0133] This transaction chain processing method is generally used in business scenarios where transaction data has high requirements for confidentiality and security, such as Figure 2 The scenario of the tax electronic invoice blockchain system shown. The disclosed embodiment provides a highly versatile secure on-chain solution that can improve the security of transaction on-chain.

[0134] like Figure 3 As shown, a transaction on-chain processing method according to an embodiment of the present disclosure may include:

[0135] Step 310: Obtain the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain in the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed;

[0136] Step 320: verify the object identity information, the Merkle tree proof, and the generated note, and after successful verification, generate a zero-knowledge proof based on the object identity information, the Merkle tree proof, and the generated note through a zero-knowledge circuit;

[0137] Step 330: Send the zero-knowledge proof to the consensus node.

[0138] Steps 310 - 330 are described in detail below.

[0139] In step 310, the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed are obtained.

[0140] The object identity information is used to identify the identity of the object that generates the transaction to be on-chain. In the disclosed embodiment, the object identity information includes the object public key and the object private key. Among them, the object public key and the object private key are public-private key pairs issued to the object by the relevant authorization agency. The object public key is open to the public, while the object private key is owned by the object and is not open to the public. In addition, the object identity information may also include a random number generated for the object. The random numbers of different objects are different.

[0141] The ticket associated with the pending transaction is used to indicate the resources that the pending transaction can consume. A ticket associated with a pending transaction can only be consumed as a whole. In actual scenarios, a pending transaction will consume previously existing tickets and generate new tickets.

[0142] For example, a bill indicates that the resource pool of object A stores 50 virtual resources. When the transaction to be on-chain indicates the transfer of 10 virtual resources from the resource pool of object A to the resource pool of object B, the original bill will be consumed and two new bills will be generated. The two new bills are that the resource pool of object A stores 40 virtual resources and the resource pool of object B stores 10 virtual resources. Based on this, the bill associated with the transaction to be on-chain is the consumed bill.

[0143] The bill Merkle tree is a binary tree that is used to record the associated bills of multiple transactions.

[0144] The Merkle tree proof is used to verify whether a certain note exists in the ticket Merkle tree.

[0145] It should be noted that the object private key in the object identity information and the Merkle tree proof of the bill associated with the transaction to be on-chain in the bill Merkle tree are private information and only known to the object itself.

[0146] In the disclosed embodiment, the process of generating the bill Merkle tree and the process of determining the bill Merkle tree certificate will be described in detail below. No further details will be given here.

[0147] The generated bill after the execution of the transaction to be on-chain refers to the new bill generated after the execution of the transaction to be on-chain consumes the existing bill associated with the transaction to be on-chain.

[0148] In the specific implementation of this embodiment, when the object wants to put a transaction with high confidentiality requirements on the chain, the object will provide the object identity information, the Merkle tree proof of the transaction-related bill to be put on the chain on the bill Merkle tree, and the public generated bill to the zero-knowledge circuit for verification on the object terminal to generate a zero-knowledge proof. Therefore, based on the collection of the object's operations on the object terminal, the object identity information, the Merkle tree proof of the transaction-related bill to be put on the chain on the bill Merkle tree, and the generated bill after the transaction to be put on the chain is executed can be determined.

[0149] In step 320, the object identity information, the Merkle tree proof and the generation ticket are verified, and after the verification is successful, a zero-knowledge proof is generated based on the object identity information, the Merkle tree proof and the generation ticket through a zero-knowledge circuit.

[0150] Zero-knowledge circuits are used to provide a carrier for verifying object identity information, Merkle tree proofs, and generated bills.

[0151] Zero-knowledge proofs are used to prove that object identity information, Merkle tree proofs, and generated bills are valid.

[0152] When this embodiment is specifically implemented, the authenticity of the object identity information, the validity of the Merkle tree proof, and the resources and addresses associated with the generated bill are first verified. When it is determined that the object identity information is authentic, the Merkle tree proof is valid, and the resources and addresses associated with the generated bill are valid, the verification is determined to be successful. Further, a zero-knowledge circuit is used to generate a zero-knowledge proof based on the object identity information, the Merkle tree proof, and the generated bill, so as to realize the security verification of the object identity information, the Merkle tree proof, and the generated bill before being put on the chain through the zero-knowledge proof.

[0153] To save space, in the disclosed embodiment, the specific implementation process of verifying the object identity information, the Merkle tree proof, and the generated ticket will be described in detail below. No further description will be given here.

[0154] In step 330, the zero-knowledge proof is sent to the consensus node.

[0155] A consensus node refers to a node on the blockchain. A consensus node has a smart contract that can verify zero-knowledge proofs and store bill Merkle trees and invalid markers.

[0156] In the disclosed embodiment, after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

[0157] The invalid mark is used to indicate the bill status of the bill associated with the transaction to be put on the chain. When a bill associated with a transaction to be put on the chain has an invalid mark, it indicates that the bill associated with the transaction to be put on the chain has been consumed and cannot be consumed again.

[0158] In the specific implementation of this embodiment, after the zero-knowledge proof is generated by the zero-knowledge circuit under the blockchain, the object will provide the zero-knowledge proof on the chain, send the zero-knowledge proof to the consensus node, and verify the zero-knowledge proof through the smart contract in the consensus node. After the zero-knowledge proof is successfully verified, an invalid mark is assigned to the bill associated with the transaction to be on the chain to update the status of the bill associated with the transaction to be on the chain to avoid repeated consumption of the bill associated with the transaction to be on the chain. At the same time, the generated bill is added to the bill Merkle tree through the smart contract of the consensus node to realize the update of the bill Merkle tree.

[0159] Through the above steps 310-330, the embodiment of the present disclosure considers that it is unsafe to directly record the resource pool information after the execution of the transaction to be chained on the blockchain. Transactions related to the same resource pool affect each other, and it is easy to infer the impact of the transaction to be chained on the resource pool from the execution results of other transactions in the same resource pool. Therefore, the embodiment of the present disclosure records the transaction as an associated bill. The execution of the transaction is regarded as the process of splitting the associated bill into the generated bill. The bill itself is isolated and the impact on the resource pool cannot be inferred. The embodiment of the present disclosure obtains the object identity information, the Merkle tree proof of the associated bill of the transaction to be chained on the bill Merkle tree, and the generated bill after the transaction to be chained is executed, and verifies it, and after the verification is successful, a zero-knowledge proof is generated through a zero-knowledge circuit and sent to the consensus node. The characteristic of the zero-knowledge proof is that it can still perform security verification before chaining without leaking the personalized information of the object. After the verification is successful, since the embodiment of the present disclosure adopts a bill-based recording method, an invalid mark is assigned to the associated bill of the transaction to be chained, and a generated bill is added to the bottom layer of the bill Merkle tree. Through the zero-knowledge proof, the verification is completed without leaking personalized information. By recording the bill instead of the resource pool, the security of the on-chain records is improved. The above process can be applied to most transactions to be on-chain and is universal.

[0160] The above is a general description of steps 310 to 330. The specific implementation of step 310, step 320 and step 330 will be described in detail below.

[0161] Detailed description of step 310

[0162] In step 310, the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed are obtained.

[0163] In blockchain, in order to maintain the consistency of the global state, a tree structure is often used to record the resource status after each transaction is executed. However, it is unsafe to directly record the resource pool information after the execution of the transaction to be on the chain on the blockchain. Transactions related to the same resource pool affect each other, and it is easy to infer the impact of the transaction to be on the chain on the resource pool from the execution results of other transactions in the same resource pool. Based on this, the embodiment of the present disclosure considers recording the transaction in the form of an associated bill in the blockchain. The execution of the transaction is regarded as the splitting process of the associated bill.

[0164] Combine the following Figure 4A and Figure 4B A detailed description of the execution process of the transaction represented by the splitting of associated notes is given.

[0165] like Figure 4A As shown, the transaction number of the first transaction is 001, and the transaction type of the transaction with transaction number 001 is resource acquisition in the resource concentration area. The transaction with transaction number 001 is used to indicate that Alice obtains a reward of 12.5 resources in a certain event. Therefore, the first note is used to indicate that Alice's address has 12.5 resources. Then, Alice executed a resource transfer transaction, transferring 6 of the 12.5 resources to Bob. Based on this, the second transaction is generated, and the second transaction is a transaction with transaction number 002. Based on the execution of the transaction with transaction number 002, the first note is split into two new notes, where one of the split notes is used to indicate that Bob's address has 6 resources, and the other split note is used to indicate that Alice's address has 6.5 resources. Further, Bob executed a resource transfer transaction, transferring 2 of the 6 resources to Lily. Based on this, the third transaction is generated, and the third transaction is a transaction with transaction number 003. Based on the execution of the transaction numbered 003, Bob's ticket is split into two new tickets, one of which is used to indicate that Bob's address owns 4 resources, and the other ticket is used to indicate that Lily's address owns 2 resources.

[0166] like Figure 4BAs shown, 100k virtual resources are stored in a resource pool, generating a resource storage transaction (transaction 0), and transaction 0 corresponds to a ticket containing 100k virtual resources. Next, a resource transfer transaction is executed based on the ticket containing 100k virtual resources, and the ticket containing 100k virtual resources is split into two independent tickets, wherein one ticket containing 40k virtual resources corresponds to transaction 1, and the other ticket containing 60k virtual resources corresponds to transaction 2. Further, a resource transfer transaction is executed based on the ticket containing 40k virtual resources, and a ticket containing 4k virtual resources corresponds to transaction 3. Transaction 3 is associated with a ticket containing 40k virtual resources. In addition, a resource transfer transaction is executed based on the ticket containing 60k virtual resources, and the ticket containing 60k virtual resources is split into two independent tickets, wherein one ticket containing 30k virtual resources corresponds to transaction 4, and the other ticket containing 30k virtual resources corresponds to transaction 5. Finally, a resource collection transaction is executed based on two tickets containing 30k virtual resources, forming a transaction 6 corresponding to a ticket containing 60k virtual resources, so that transaction 6 is associated with a ticket containing 60k virtual resources. It can be seen that the tickets associated with each transaction are different. A ticket will be consumed as a whole in the execution of a transaction.

[0167] From the above, we can see that when the execution process of a transaction is represented by the splitting of associated bills, each bill is isolated. At the same time, the bill is indivisible. A bill will be consumed as a whole in a transaction. After the transaction is executed, the consumed bill will become invalid and replaced by a new bill. Therefore, recording the transaction in the form of associated bills in the blockchain can effectively improve the security of the transaction on the chain.

[0168] In the embodiment of the present disclosure, when using bills to represent transactions, the bills can be maintained as an array. However, arrays often cannot represent the global transaction status well. Based on this, the embodiment of the present disclosure provides a bill maintenance solution based on a Merkle tree, which organizes bills into a bill Merkle tree for maintenance and management, and can effectively improve the verification efficiency of bills.

[0169] It should be noted that the bill Merkle tree of the embodiment of the present disclosure is generated and maintained by the smart contract in the consensus node.

[0170] Combine the following Figure 5 ,and Figure 6 A detailed description of the process of generating the bill Merkle tree.

[0171] Please refer to Figure 5 In one embodiment, the process of generating a bill Merkle tree includes but is not limited to the following steps 510-520:

[0172] Step 510: Use multiple transaction bills as the bottom layer features of the bill Merkle tree;

[0173] Step 520: In response to the queue satisfying a predetermined condition, the local transactions to be uploaded to the chain in the queue are packaged and sent to the second consensus node.

[0174] Steps 510 - 520 are described in detail below.

[0175] In step 510, multiple transaction tickets are used as features of the lowest level of the ticket Merkle tree.

[0176] The bill Merkle tree of the embodiment of the present disclosure is usually a binary tree, or a multi-branch tree. The bill Merkle tree has all the characteristics of a tree structure, and the tree structure often includes multiple nodes, including at least one leaf node and a root node, and usually also includes multiple intermediate nodes between the leaf node and the root node.

[0177] In the specific implementation of this embodiment, first, for multiple transaction bills, bill indexes are assigned in order according to the order in which the transaction bills are generated, and a predetermined summary algorithm is used to perform summary operations on each transaction bill to obtain a summary of each transaction bill. Next, each transaction bill is used as the feature of the lowest level of the bill Merkle tree in order according to the bill index, and the bill index and summary of each transaction bill are used as feature values. Based on this, multiple leaf nodes at the lowest level of the bill Merkle tree are generated.

[0178] For example, the consensus node first receives transaction 1 to be on-chain, "Employee A reimburses 1,000 resources at Enterprise B", and then receives transaction 2 to be on-chain, "Employee C reimburses 500 resources at Enterprise D". The transaction-associated note of transaction 1 to be on-chain is used as the first node of the bottom layer, and the transaction-associated note of transaction 2 to be on-chain is used as the second node of the bottom layer.

[0179] The digest algorithm used for the digest of the transaction ticket associated with each transaction to be on-chain can be one of the following:

[0180] (1) A fixed digest algorithm that is pre-specified by the consensus node and is the same for the entity to which the transaction ticket of each transaction to be on-chain belongs.

[0181] (2) The consensus node pre-assigns different digest algorithms to the entity to which the transaction ticket of each local transaction to be put on the chain belongs. Since this embodiment uses different digest algorithms for different entities, it increases the difficulty of cracking the transaction to be put on the chain from the digest value, and improves the security of the transaction to be put on the chain.

[0182] In step 520, starting from the features of the lowest layer, two adjacent features of each layer are connected to generate a feature of a higher layer based on a predetermined summary algorithm, until the root feature of the bill Merkle tree is generated.

[0183] When this embodiment is implemented, each bottom-level feature of the bill Merkle tree corresponds to a single transaction bill, and each bottom-level feature is the feature of the transaction bill (the features of the transaction bill are the summary and the bill index). Two adjacent features of each layer of the bill Merkle tree are connected to generate a feature of a higher layer, that is, each feature in the higher layer is obtained by calculating the two adjacent features of the lower layer (the summary value in the feature of the higher layer can be obtained by performing a summary calculation on the summary values ​​of the two adjacent features of the lower layer). This process is repeated until the root feature of the bill Merkle tree is generated, and a complete bill Merkle tree is obtained.

[0184] like Figure 6 As shown, object 1 can determine that note 1 is owned by itself through object private key 1 and digest algorithm off-chain; object 2 can determine that note 2 is owned by itself through object private key 2 and digest algorithm off-chain; object 3 can determine that note 3 is owned by itself through object private key 3 and digest algorithm off-chain, and can also determine that note 4 is owned by itself through object private key 4 and digest algorithm. However, on the blockchain, notes 1, 2, 3 and 4 are stored in a mixed manner. Except for the object that owns the note, other objects cannot determine which object owns each note. A note Merkle tree is maintained in the target contract. According to the order in which the notes associated with each transaction to be on-chain are received, notes 1, 2, 3 and 4 are used as the first node, second node, third node and fourth node of the lowest level of the note Merkle tree. Then, the summary of note 1 and the summary of note 2 are concatenated and digested to obtain the feature of the next level (digest value 1); the summary of note 3 and the summary of note 4 are concatenated and digested to obtain the feature of the next level (digest value 2). Finally, digest value 1 and digest value 2 are concatenated and digest operation is performed to obtain the root node of the bill Merkle tree.

[0185] Through the above steps 510-520, the disclosed embodiment maintains the received multiple transaction-related bills to be chained in the target contract in the form of a bill Merkle tree, and makes the root node of the bill Merkle tree public, so that each object can verify the bills associated with the transaction to be chained based on its own object private key and the summary information related to the bills it owns on the bill Merkle tree, so as to improve the security of the transaction chain. In addition, the bill Merkle tree can also reflect all the bills associated with the consensus node, so as to achieve the overall state maintenance of the transaction associated with the consensus node and improve the consistency of the global state of the transaction.

[0186] Detailed description of step 320

[0187] In step 320, the object identity information, the Merkle tree proof and the generation ticket are verified, and after the verification is successful, a zero-knowledge proof is generated based on the object identity information, the Merkle tree proof and the generation ticket through a zero-knowledge circuit.

[0188] Please refer to Figure 7 In one embodiment, the process of verifying the object identity information, the Merkle tree proof, and the generated ticket includes but is not limited to the following steps 710-750:

[0189] Step 710: Perform a first verification based on the object identity information and the ticket associated with the transaction to be uploaded to the chain;

[0190] Step 720: If it is determined that the first verification is passed, a second verification is performed on the bill associated with the transaction to be on-chain based on the Merkle tree proof;

[0191] Step 730: If it is determined that the second verification is passed, a third verification is performed on the invalidation mark assigned to the ticket associated with the transaction to be on-chain;

[0192] Step 740: If it is determined that the third verification is passed, a fourth verification is performed on the generated bill;

[0193] Step 750: If it is determined that the fourth verification is passed, it is determined that the verification is successful.

[0194] Steps 710-750 are described in detail below.

[0195] In step 710, a first verification is performed based on the object identity information and the ticket associated with the transaction to be on-chain.

[0196] The first verification is used to verify whether the object can use the object private key in the object identity information when uploading the bill associated with the transaction to be uploaded to the chain.

[0197] When this embodiment is specifically implemented, it can be verified whether the bill indicated by the object private key in the object identity information is a bill associated with the transaction to be on-chained. If it is determined that the bill indicated by the object private key in the object identity information is a bill associated with the transaction to be on-chained, it is determined that the first verification is passed. If it is determined that the bill indicated by the object private key in the object identity information is not a bill associated with the transaction to be on-chained, it is determined that the first verification is not passed.

[0198] In step 720, if it is determined that the first verification is passed, a second verification is performed on the bill associated with the transaction to be on-chain based on the Merkle tree proof.

[0199] The second verification is used to verify that the bill associated with the transaction to be on-chain is a node in the bill Merkle tree.

[0200] In the specific implementation of this embodiment, the bypass path of the bill associated with the transaction to be on-chain and the bypass features in the bypass path are first determined based on the Merkle tree proof, wherein the bypass features include the digest of the bypass bill and the bill index, as well as the digests of other bypass features. Next, a Merkle root feature is calculated based on the bypass path of the bill associated with the transaction to be on-chain, the bypass features in the bypass path, and the digest of the bill associated with the transaction to be on-chain. Finally, based on the consistency of the Merkle root feature and the root feature of the public bill Merkle tree, it is determined whether the second verification is passed.

[0201] In step 730, if it is determined that the second verification is passed, a third verification is performed on the invalidation flag assigned to the ticket associated with the transaction to be on-chain.

[0202] The third verification is used to verify whether the invalidation mark assigned to the ticket associated with the transaction to be on-chain is correct.

[0203] In the specific implementation of this embodiment, since the transaction-associated ticket to be put on the chain can be calculated by the object according to the private parameters, first, with the authorization permission of the object, an invalidation mark is calculated using the private parameters of the object; then, the invalidation mark assigned to the transaction-associated ticket to be put on the chain is compared with the calculated invalidation mark. According to the consistency of the two invalidation marks, it is determined whether the third verification is passed.

[0204] In step 740, if it is determined that the third verification is passed, a fourth verification is performed on the generated ticket.

[0205] The fourth verification is used to verify whether the resource transfer address and the number of transferred resources associated with the generated ticket meet the requirements.

[0206] In the specific implementation of this embodiment, first, the resource transfer address associated with the generated bill is verified to determine whether the resource transfer address is the address pointed to by the bill associated with the transaction to be chained. Then, after determining that the resource transfer address associated with the generated bill is correct, determine whether the number of transferred resources associated with the generated bill is not greater than the total resources associated with the bill associated with the transaction to be chained. Based on the comparison of the number of resources, determine whether the generated bill has been verified.

[0207] In step 750, if it is determined that the fourth verification is passed, it is determined that the verification is successful.

[0208] In the specific implementation of this embodiment, if it is determined that the fourth verification is passed, it indicates that the object identity information, the Merkle tree proof and the generated bill are all verified correctly, so the verification is determined to be successful. If the fourth verification fails, it indicates that there is an error in the generated bill, so the verification is determined to be failed.

[0209] Through the above steps 710-750, the embodiment of the present disclosure uses zero-knowledge circuits to perform multiple verifications on the object identity information, Merkle tree proofs, and generated notes, so as to prove the validity of the object identity information, Merkle tree proofs, and generated notes off-chain, and improve the verification security before going on-chain. After the object identity information, Merkle tree proofs, and generated notes are verified to be correct, a zero-knowledge proof is generated through a zero-knowledge circuit, and effective proof of the object identity information, Merkle tree proofs, and generated notes is achieved without disclosing the object's personal information, and the object's transaction operation authority and the specific transaction operation method of the object can be reliably determined.

[0210] Please refer to Figure 8 In one embodiment, the process of performing the first verification based on the object identity information and the ticket associated with the transaction to be on-chain includes but is not limited to the following steps 810-830:

[0211] Step 810: Perform a digest operation on the object private key in the object identity information to obtain an object digest value;

[0212] Step 820: If the object summary value is consistent with the ticket associated with the transaction to be uploaded, it is determined that the first verification is passed;

[0213] Step 830: If the object summary value is inconsistent with the ticket associated with the transaction to be on-chain, it is determined that the first verification fails.

[0214] Steps 810-830 are described in detail below.

[0215] In step 810, a digest operation is performed on the object private key in the object identity information to obtain an object digest value.

[0216] The object digest value is the digest result of the object's private key.

[0217] When this embodiment is implemented, a preset digest algorithm may be used to perform a digest operation on the object private key in the object identity information, and the digest result may be used as the object digest value, wherein the object digest value is represented as hash(sk), wherein sk is the object private key provided by the object.

[0218] In step 820, if the object summary value is consistent with the ticket associated with the transaction to be on-chain, it is determined that the first verification is passed.

[0219] When this embodiment is implemented, the object summary value is first compared with the ticket associated with the transaction to be chained. If the object summary value is consistent with the ticket associated with the transaction to be chained, it indicates that the ticket indicated by the object private key in the object identity information is the ticket associated with the transaction to be chained, and the object has the authority to operate the ticket associated with the transaction to be chained, so it is determined that the first verification is passed.

[0220] In step 830, if the object summary value is inconsistent with the ticket associated with the transaction to be on-chained, it is determined that the first verification fails.

[0221] In the specific implementation of this embodiment, if the object summary value is inconsistent with the ticket associated with the transaction to be chained, it indicates that the ticket indicated by the object private key in the object identity information is not the ticket associated with the transaction to be chained, and the object does not have the authority to operate the ticket associated with the transaction to be chained, so it is determined that the first verification fails.

[0222] Through the above steps 810-830, the disclosed embodiment compares the object private key provided by the object with the ticket associated with the transaction to be chained to determine whether the object private key provided by the object corresponds to the ticket associated with the transaction to be chained. Further, when the summary result of the object private key corresponds to the ticket associated with the transaction to be chained, it is considered that the object providing the object private key has the authority to use the ticket associated with the transaction to be chained, which can effectively improve the security and accuracy of the object identity authentication.

[0223] Please refer to Fig. 9 In one embodiment, the Merkle tree proof includes the bypass note index of the note associated with the transaction to be on-chain in the note Merkle tree, the bypass note summary value, and the bypass feature summary value.

[0224] The bypass bill index refers to the index of the bill that generates the upper layer features together with the bill associated with the transaction to be on-chain.

[0225] The bypass bill summary value refers to the summary of the bill that is associated with the transaction to be on-chain and generates the upper-layer features together.

[0226] The bypass feature summary value refers to a feature summary value that is used together with each summary value in the path connecting the transaction ticket to be on-chain and the root node to generate a higher-level summary value.

[0227] The process of performing a second verification of the bill associated with the transaction to be on-chain based on the Merkle tree proof includes but is not limited to the following steps 910-940:

[0228] Step 910: Determine the bill summary value of the bill associated with the transaction to be on-chain in the bill Merkle tree;

[0229] Step 920: Calculate the to-be-verified root node digest of the bill Merkle tree based on the bill digest value, the bypass bill index, and the bypass bill digest value;

[0230] Step 930: If it is determined that the digest of the root node to be verified is consistent with the public digest of the root node, it is determined that the second verification is passed;

[0231] Step 940: If it is determined that the root node digest to be verified is inconsistent with the public root node digest, it is determined that the second verification fails.

[0232] Steps 910-940 are described in detail below.

[0233] In step 910, the bill summary value of the bill associated with the transaction to be on-chain in the bill Merkle tree is determined.

[0234] The bill summary value is used to indicate the summary result of the bill associated with the transaction to be on-chain.

[0235] In the specific implementation of this embodiment, since the relevant information of the transaction ticket owned by the object is often recorded on the local side, the object terminal can query the local record of the transaction-related ticket to be on-chain in the ticket Merkle tree.

[0236] In step 920, the to-be-verified root node digest of the bill Merkle tree is calculated based on the bill digest value, the bypass bill index, and the bypass bill digest value.

[0237] The root node summary to be verified refers to the summary of the root node of the tree structure generated according to the bill summary value and the bypass feature of the bill associated with the transaction to be on-chain in the bill Merkle tree.

[0238] When this embodiment is implemented, the position of the bill associated with the transaction to be on-chain in the bill Merkle tree is first determined according to the bypass bill index. Furthermore, the bill summary value and the bypass bill summary value are first concatenated, and a summary operation is performed on the concatenation result to obtain the summary value of the feature of the previous layer. Next, the summary value of the feature of the previous layer is concatenated and the bypass feature summary value of the corresponding bypass feature is summed up to generate the summary value of the feature of the next layer, and so on, until the summary value of the root node of the tree is generated, and the summary value of the root node of the tree is used as the summary of the root node to be verified.

[0239] In step 930, if it is determined that the root node digest to be verified is consistent with the public root node digest, it is determined that the second verification is passed.

[0240] The public root node digest refers to the digest value of the root node of the bill Merkle tree in the target contract (smart contract).

[0241] When this embodiment is implemented, the root node digest to be verified is compared with the public root node digest. If it is determined that the root node digest to be verified is consistent with the public root node digest, it indicates that the bill associated with the transaction to be on-chain is a node in the bill Merkle tree of the target contract, so the second verification is determined to be passed.

[0242] In step 940, if it is determined that the root node digest to be verified is inconsistent with the public root node digest, it is determined that the second verification fails.

[0243] When this embodiment is implemented, the root node digest to be verified is compared with the public root node digest. If it is determined that the root node digest to be verified is inconsistent with the public root node digest, it indicates that the bill associated with the transaction to be on-chain is not a node in the bill Merkle tree in the target contract, so it is determined that the second verification fails.

[0244] like Fig.10 As shown, the object uses the note 3 it owns as the note associated with the transaction to be on the chain, and determines the position of the note associated with the transaction to be on the chain in the note Merkle tree. For note 3 in the note Merkle tree, the nodes on the connection path formed by note 3 and the root node include digest value 2, digest value 5, note 3 and root node. According to the nodes on the connection path, it is determined that the bypass features of note 3 include bypass feature 1 (note 4), bypass feature 2 (digest value 1) and bypass feature 3 (digest value 6). Based on this, the note index and digest value of note 4, as well as the position index of digest value 1 and digest value 6, will be provided in the Merkle tree proof. Further, the summary of the root node to be verified of the note Merkle tree is calculated based on each bypass feature. First, the summary 3 of note 3 and the summary 4 of note 4 are concatenated and then a summary operation is performed to obtain a first summary result. Then, the first summary result and the summary value 1 are concatenated and then a summary operation is performed to obtain a second summary result. Furthermore, the second summary result and the summary value 6 are concatenated and then a summary operation is performed to obtain a third summary result, and the third summary result is used as the summary of the root node to be verified. Therefore, the third summary result is compared with the public root node summary of the bill Merkle tree. If the third summary result is consistent with the public root node summary, it indicates that the bill associated with the transaction to be chained determined by the object is a node in the bill Merkle tree. If the third summary result is inconsistent with the public root node summary, it indicates that the bill associated with the transaction to be chained determined by the object is not a node in the bill Merkle tree.

[0245] Through the above steps 910-940, the embodiment of the present disclosure verifies whether the object-determined transaction-to-be-chained associated bill exists in the target contract's bill Merkle tree based on the consistency of the root node of the bill Merkle tree. The bill-to-be-chained transaction-associated bill can be verified on the premise that each bill in the bill Merkle tree and each node feature have good security, thereby improving the security of transaction verification.

[0246] Please refer to Fig.11 In one embodiment, the process of performing a third verification on the invalidation flag assigned to the ticket associated with the transaction to be on-chain includes but is not limited to the following steps 1110-1130:

[0247] Step 1110: for the transaction-associated bill to be put on the chain, based on the object identity information and the Merkle tree proof, generate a target invalidation mark for the transaction-associated bill to be put on the chain;

[0248] Step 1120: If it is determined that the target invalid mark is consistent with the invalid mark, it is determined that the third verification is passed;

[0249] Step 1130: If it is determined that the target invalid flag and the invalid flag are inconsistent, it is determined that the third verification fails.

[0250] Steps 1110 - 1130 are described in detail below.

[0251] In step 1110, for the transaction-associated bill to be put on the chain, a target invalidation mark of the transaction-associated bill to be put on the chain is generated based on the object identity information and the Merkle tree proof.

[0252] The target invalid marking is the invalid marking computed by the zero-knowledge circuit.

[0253] When this embodiment is implemented, the specific implementation process of generating the target invalid mark of the transaction-related bill to be on-chain in step 1110 will be described in detail below. No further description will be given here.

[0254] In step 1120, if it is determined that the target invalid flag is consistent with the invalid flag, it is determined that the third verification is passed.

[0255] When this embodiment is implemented, the target invalidation mark and the invalidation mark are first compared. If it is determined that the target invalidation mark and the invalidation mark are consistent, it means that the invalidation mark calculated and publicly input by the object itself is correct, so it is determined that the third verification is passed.

[0256] In step 1130, if it is determined that the target invalid flag and the invalid flag are inconsistent, it is determined that the third verification fails.

[0257] When this embodiment is implemented, the target invalidation mark and the invalidation mark are first compared. If it is determined that the target invalidation mark and the invalidation mark are inconsistent, it means that the invalidation mark calculated and publicly input by the object itself is incorrect, so it is determined that the third verification fails.

[0258] Through the above steps 1110-1130, the embodiment of the present disclosure compares the invalid mark calculated and publicly input by the object itself with the target invalid mark calculated in the zero-knowledge circuit, thereby verifying whether the invalid mark calculated and publicly input by the object itself is incorrect. After determining that the invalid mark calculated and publicly input by the object itself is correct, after the consensus node successfully proves the zero-knowledge, the invalid mark is recorded as the final invalid mark of the transaction-related bill to be put on the chain, thereby preventing the transaction-related bill to be put on the chain from being repeatedly consumed.

[0259] Please refer to Fig.12In one embodiment, the process of generating a target invalidation mark includes but is not limited to the following steps 1210-1230:

[0260] Step 1210: extract the bypass note index of the note associated with the transaction to be on-chain from the Merkle tree proof;

[0261] Step 1220: Concatenate the object private key and the bypass ticket index in the object identity information to obtain a concatenation result;

[0262] Step 1230: perform a digest operation on the concatenation result to obtain a target invalidation mark.

[0263] Steps 1210 - 1230 are described in detail below.

[0264] In step 1210, the bypass note index of the note associated with the transaction to be on-chain is extracted from the Merkle tree proof.

[0265] The bypass ticket index is used to identify the location of the bypass ticket that is used to generate the digest value of the previous layer together with the ticket associated with the transaction to be uploaded.

[0266] In the specific implementation of this embodiment, since the bypass note index exists in the Merkle tree proof provided by the object, the bypass note index of the note associated with the transaction to be on-chain can be extracted from the Merkle tree proof with authorization.

[0267] In step 1220, the object private key and the bypass ticket index in the object identity information are concatenated to obtain a concatenation result.

[0268] When this embodiment is implemented, the object private key and the bypass ticket index in the object identity information are concatenated in a predetermined order to obtain a concatenation result.

[0269] The predetermined order may be that the object private key is in front and the bypass ticket index is in the back; the predetermined order may also be that the object private key is in the back and the bypass ticket index is in the front; there is no restriction.

[0270] In step 1230, a digest operation is performed on the concatenation result to obtain a target invalidation mark.

[0271] When this embodiment is implemented, a digest algorithm is used to perform a digest operation on the concatenation result to obtain a target invalidation mark.

[0272] It should be noted that, in the embodiment of the present disclosure, the invalid flag calculated and publicly input by the object itself can also be calculated by the object itself according to steps 1210 - 1230 .

[0273] Among them, the invalid mark can be expressed as Nullifier = Hash (sk, merkle_path_index), Nullifier refers to the invalid mark; sk refers to the object private key; merkle_path_index refers to the bypass bill index of the bill associated with the transaction to be on the chain.

[0274] Since the bypass notes of different transaction-related notes to be put on the chain are different, the invalidation marks of different transaction-related notes to be put on the chain are different. Each invalidation mark will uniquely correspond to a transaction-related note to be put on the chain.

[0275] Through the above steps 1210-1230, the disclosed embodiment has good confidentiality because the object private key and Merkle tree proof of the object are private. The concatenated summary result of the object private key and the bill index in the Merkle tree proof is used as an invalid mark, which can improve the uniqueness of the invalid mark and reduce the risk of repeated consumption of bills associated with the transaction to be on the chain.

[0276] Please refer to Fig.13 In one embodiment, when an object transfers resources to multiple other objects, multiple new bills are often generated based on the resource transfer transaction. The multiple new bills are called sub-bills of the generated bill, and each sub-bill is an independent bill.

[0277] Specifically, the process of performing the fourth verification on the generated bill includes but is not limited to the following steps 1310-1330:

[0278] Step 1310: Integrate the resources indicated by the multiple sub-notes to obtain a first resource;

[0279] Step 1320: If it is determined that the first resource is consistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification is passed;

[0280] Step 1330: If it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification fails.

[0281] Steps 1310 - 1330 are described in detail below.

[0282] In step 1310, the resources indicated by the multiple sub-notes are integrated to obtain a first resource.

[0283] A sub-note refers to one of the generated notes. For example, when the transaction note to be uploaded is split into three parts, the generated note claimed in the embodiment of the present disclosure contains three independent sub-notes.

[0284] The resources indicated by the sub-ticket refer to the number of resources in the sub-ticket. For example, if a sub-ticket indicates that there are 10 virtual resources in the resource pool address of object A, then the resource indicated by the sub-ticket is 10.

[0285] The first resource is the sum of the resources indicated by all sub-tickets.

[0286] In the specific implementation of this embodiment, the resources indicated by each sub-note are first determined, and then the resources indicated by all sub-notes are summed to obtain the first resource.

[0287] In step 1320, if it is determined that the first resource is consistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification is passed.

[0288] The second resource refers to the number of resources in the ticket associated with the transaction to be uploaded to the chain.

[0289] When this embodiment is implemented, the first resource is first compared with the second resource. If it is determined that the first resource is consistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it indicates that the ticket associated with the transaction to be on-chain and the resource for generating the ticket generated after the transaction to be on-chain is executed have not changed, so it is determined that the fourth verification is passed.

[0290] In step 1330, if it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification fails.

[0291] When this embodiment is implemented, the first resource and the second resource are first compared. If it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it indicates that the ticket associated with the transaction to be on-chain and the resources of the generated ticket generated after the transaction to be on-chain is executed have changed, and there is an error in the resource of the sub-ticket or a sub-ticket is missing, so it is determined that the fourth verification fails.

[0292] For example, the fourth verification passes when node=Node1+Node2+...+Nodek, where k is a positive integer greater than 0. Node represents the bill associated with the transaction to be put on the chain; Node1, Node2,..., Nodek represent each sub-bill.

[0293] Through the above steps 1310-1330, the embodiment of the present disclosure can verify whether there are resource errors or missing bills in the generated bills by comparing the bills associated with the transaction to be uploaded to the chain with all the generated bills, thereby improving the verification accuracy of the generated bills, so that the generated bills subsequently recorded on the chain are accurate, thereby improving the security of the bill records on the chain.

[0294] Please refer to Fig.14In one embodiment, the process of performing the fourth verification on the generated ticket includes but is not limited to the following steps 1410-1430:

[0295] Step 1410: Obtain the blockchain address associated with the generated bill;

[0296] Step 1420: verify the blockchain address.

[0297] Step 1430: If it is determined that the blockchain address verification is passed, then it is determined that the fourth verification is passed.

[0298] Steps 1410-1430 are described in detail below.

[0299] In step 1410, the blockchain address associated with the generated note is obtained.

[0300] The blockchain address refers to the resource pool address selected by the object to transfer resources to when performing resource extraction operations.

[0301] In the specific implementation of this embodiment, when the object performs a resource extraction operation on the object terminal, it is necessary to verify whether the resource pool address indicated by the resource extraction operation to transfer the resource meets the requirements. Based on this, when the object performs a resource extraction operation on the object terminal, the resource pool address indicated by the resource extraction operation is input, so the received resource pool address can be used as the blockchain address associated with the generated bill.

[0302] In step 1420, address verification is performed on the blockchain address.

[0303] In the specific implementation of this embodiment, when verifying the blockchain address, in order to enable the smart contract in the consensus node to transfer resources according to the blockchain address provided by the object, it is necessary to verify the validity of the blockchain address. Based on this, the preset protocol can be called to verify the blockchain address.

[0304] In step 1430, if it is determined that the blockchain address verification is passed, it is determined that the fourth verification is passed.

[0305] In the specific implementation of this embodiment, if the blockchain address is determined to be valid according to the called preset protocol, the blockchain address verification is determined to be passed, and the fourth verification is determined to be passed. If the blockchain address is determined to be not valid according to the called preset protocol, the blockchain address verification is determined to be failed, and the fourth verification is determined to be failed.

[0306] Through the above steps 1410-1430, the embodiment of the present disclosure takes into account that when an object performs a resource extraction operation, it is necessary to verify the validity of the address of the extracted resource provided by the object; at the same time, the blockchain address associated with the generated bill is proved to meet the requirements through the zero-knowledge circuit and the preset protocol, so that the smart contract of the consensus node transfers resources according to the blockchain address after successfully verifying the zero-knowledge proof.

[0307] Please refer to Fig.15 In one embodiment, the process of performing the fourth verification on the generated ticket includes but is not limited to the following steps 1510-1520:

[0308] Step 1510: Determine the first resource amount associated with the generated ticket and the second resource amount associated with the ticket associated with the transaction to be uploaded to the chain;

[0309] Step 1520: If it is determined that the first resource amount is less than or equal to the second resource amount, it is determined that the fourth verification is passed.

[0310] Steps 1510-1520 are described in detail below.

[0311] In step 1510, a first resource amount associated with the generated ticket and a second resource amount associated with the ticket associated with the transaction to be uploaded are determined.

[0312] The first resource amount is used to indicate the total amount of resources associated with the generated ticket that is publicly determined by the object when the object performs a resource extraction operation.

[0313] The second resource amount is used to indicate the total amount of resources associated with the bill associated with the transaction to be uploaded to the chain.

[0314] In the specific implementation of this embodiment, with authorization permission, the first resource amount associated with the generated ticket is obtained from the public input of the object. Further, with authorization permission, the resource amount indicated in the ticket associated with the transaction to be chained is extracted as the second resource amount.

[0315] In step 1520, if it is determined that the first resource amount is less than or equal to the second resource amount, it is determined that the fourth verification is passed.

[0316] When this embodiment is specifically implemented, the first resource amount and the second resource amount are first compared. If the first resource amount is greater than the second resource amount, it means that the total amount of resources to be extracted publicly determined by the object exceeds the maximum amount of resources stored in the ticket associated with the transaction to be chained, and the resource extraction operation is not in line with common sense and cannot be implemented, so it is determined that the fourth verification fails. If the first resource amount is less than or equal to the second resource amount, it means that the total amount of resources to be extracted publicly determined by the object does not exceed the maximum amount of resources stored in the ticket associated with the transaction to be chained, and the resource extraction operation can be implemented, so it is determined that the fourth verification passes.

[0317] Through the above steps 1510-1520, the embodiment of the present disclosure takes into account that when an object performs a resource extraction operation, it is necessary to verify the validity of the amount of resources to be extracted determined by the object; at the same time, a zero-knowledge circuit is used to prove that the amount of resources to be extracted determined by the object meets the requirements, so that the smart contract of the consensus node transfers resources according to the amount of resources to be extracted after successfully verifying the zero-knowledge proof.

[0318] like Fig.16As shown, it is the transaction chaining process based on zero-knowledge proof in the disclosed embodiment. Specifically, when generating a zero-knowledge proof, the object private key and the Merkle tree proof are used as private input parameters of the zero-knowledge circuit, and the root summary of the Merkle tree of the bill provided by the object, the invalid mark, and the generated bill are used as public input parameters of the zero-knowledge circuit. It should be noted that the public input parameters of the zero-knowledge circuit are parameters that need to be executed in the target contract after verification by the zero-knowledge circuit. For example, the target contract needs to verify that the root summary of the bill Merkle tree corresponding to the zero-knowledge proof is consistent with the root summary of the bill Merkle tree maintained in the target contract. The invalid mark is what the target contract needs to record, and the generated bill is to be added to the bill Merkle tree maintained in the target contract after the on-chain transaction is executed. When a transaction is put on the chain based on zero-knowledge proof, the object first provides the above-mentioned private input parameters and public input parameters to the zero-knowledge circuit, and the various information provided by the object is verified by the zero-knowledge circuit off the chain. When the verification is successful, the zero-knowledge circuit will generate a zero-knowledge proof to indicate that the private input parameters provided by the object are valid through the zero-knowledge proof. The specific implementation process of verifying the various information provided by the object off the chain through the zero-knowledge circuit is similar to the specific implementation process of the above steps 710-750. Further, after the zero-knowledge proof is generated, the zero-knowledge proof and the public input parameters are submitted to the chain together, and the consensus node on the blockchain verifies the zero-knowledge proof according to the target contract. When the zero-knowledge proof verification fails, the transaction will be returned. When the zero-knowledge proof verification is successful, the target contract in the consensus node will add the generated bill to the bill Merkel tree and record the invalid mark. In addition, the target contract in the consensus node will also execute the transaction of transferring resources to the specified blockchain address, and its specific implementation process is similar to the specific implementation process of the above step 330. In order to save space, it will not be repeated.

[0319] Detailed description of step 330

[0320] In step 330, the zero-knowledge proof is sent to the consensus node, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

[0321] Please refer to Fig.17 In one embodiment, the process of assigning an invalid flag to the bill associated with the transaction to be on-chain and adding the generated bill to the bill Merkle tree includes but is not limited to the following steps 1710-1730:

[0322] Step 1710: Add the invalid flag assigned to the bill associated with the transaction to be on-chain to the target contract;

[0323] Step 1720: Search the bill Merkle tree in the target contract.

[0324] Step 1730: Add the generated bill to the bottom layer of the found bill Merkle tree.

[0325] Steps 1710-1730 are described in detail below.

[0326] In step 1710, the invalid flag assigned to the ticket associated with the transaction to be on-chain is added to the target contract.

[0327] The target contract refers to the smart contract created in the consensus node. After the smart contract is created, a contract account corresponding to the smart contract appears on the blockchain and has a specific address; for example, "0x68e12cf284..." in the consensus node represents the address of the created smart contract; the contract code (Code) and account storage (Storage) will be saved in the account storage of the contract account. The behavior of the smart contract is controlled by the contract code, and the account storage of the smart contract saves the state of the contract. In other words, the smart contract generates a virtual account on the blockchain that contains the contract code and account storage.

[0328] The target contract can be executed independently in each consensus node in the blockchain network in a prescribed manner, and all execution records and data are stored on the blockchain. Therefore, when such a transaction is executed, the blockchain will store transaction credentials that cannot be tampered with or lost.

[0329] The target contract in the disclosed embodiment is capable of chaining transactions to be chained that have high confidentiality requirements. At the same time, the target contract is also used to maintain a bill Merkle tree and invalid marks of transaction bills consumed in the bill Merkle tree.

[0330] In the specific implementation of this embodiment, the invalid flag assigned to the bill associated with the transaction to be on-chain is first determined. Then, the invalid flag assigned to the bill associated with the transaction to be on-chain is added to the invalid flag table of the target contract to update the invalid flag stored in the target contract.

[0331] It should be noted that the target contract indicates to the outside that there is a new invalid mark, but the public does not know which transaction-associated bill to be on-chain in the bill Merkle tree the invalid mark corresponds to.

[0332] In step 1720, the note Merkle tree is looked up in the target contract.

[0333] In the specific implementation of this embodiment, when multiple types of resource transfers are involved, resource transfer transactions of different types of resources often construct bill Merkle trees to record the execution of transactions. Based on this, multiple bill Merkle trees are often maintained in the target contract. Since the root node digests of different bill Merkle trees are different, and the root node digests of each bill Merkle tree are open to the public. Therefore, the bill Merkle tree whose root node digest is consistent with the root node digest provided by the object can be found in the target contract according to the root node digest provided by the object.

[0334] In step 1730, the generated bill is added to the lowest level in the found bill Merkle tree.

[0335] In the specific implementation of this embodiment, since the generated bill is a newly generated bill, based on this, the generated bill is added to the lowest level in the found bill Merkle tree, so as to realize the addition of the lowest level node in the bill Merkle tree. In addition, according to the reception time of the generated bill, the generated bill is assigned a corresponding bill index, and the summary value of the generated bill is calculated using the summary algorithm, and the bill index and the summary value are stored as the characteristic value of the generated bill. Among them, the generated bill added at the lowest level in the bill Merkle tree is often located to the right of the bill associated with the transaction to be chained.

[0336] like Fig.18A As shown in the figure, the target contract stores a bill Merkle tree and an invalid mark queue. Among them, the bottom layer of the bill Merkle tree contains four bills, namely bill 1, bill 2, bill 3 and bill 4. Bill 1 has index 1 and summary 1, bill 2 has index 2 and summary 2, bill 3 has index 3 and summary 3, and bill 4 has index 4 and summary 4. The invalid mark queue contains 3 invalid marks, namely invalid mark 1, invalid mark 2 and invalid mark 3. The root node and each invalid mark of the bill Merkle tree in the target contract are open to the public, but the public cannot determine which bill each invalid mark is an invalid mark of, so that the bill status has better security and confidentiality.

[0337] like Fig.18BAs shown, the invalidation mark of the bill owned by each object is jointly determined based on the bypass feature (i.e., Merkle proof) of the object private key and the bill in the Merkle tree, and the object private key and Merkle proof can only be determined by the object itself, and others cannot know it. Therefore, specifically, after consuming bill 4, the object inputs the private object private key 4 and Merkle proof, and the invalidation mark 3 calculated by itself into the zero-knowledge circuit, and verifies whether the invalidation mark 3 is calculated by the object private key 4 and Merkle proof through the zero-knowledge circuit off-chain. When it is verified that the invalidation mark 3 is indeed calculated by the object private key 4 and Merkle proof, a zero-knowledge proof is generated, and the zero-knowledge proof and invalidation mark 3 are submitted to the blockchain, and an invalidation mark 3 is added to the invalidation mark queue in the target contract. Since other objects only observe that an invalidation mark 3 is added to the target contract, but do not know which bill the invalidation mark 3 corresponds to. Other objects cannot determine the correlation between the bill and the invalidation mark based only on the bill and invalidation mark in the target contract.

[0338] Through the above steps 1710-1730, the embodiment of the present disclosure records the transaction as an associated bill. The execution of the transaction is regarded as the process of splitting the associated bill into a generated bill. After determining that the zero-knowledge proof submitted to the chain is successfully verified, the invalid mark assigned to the associated bill of the transaction to be chained is added to the target contract to achieve the status update of the associated bill of the transaction to be chained. At the same time, the generated bill is added to the bottom layer of the bill Merkle tree maintained by the target contract to achieve the status update of the bill Merkle tree. Since the target contract only has multiple invalid marks and a bill Merkle tree composed of multiple independent bills, the public cannot determine the correlation between the bill and the invalid mark, which can better eliminate the mutual influence of transactions related to the same resource pool and improve the security of the chain records.

[0339] In the embodiment of the present disclosure, the bill associated with the transaction to be chained corresponds to the original resource, and the transaction to be chained is a resource transfer transaction that transfers the target resource from the original resource; the generated bill includes a first bill and a second bill, the first bill corresponds to the target resource, and the second bill corresponds to the difference resource between the original resource and the target resource.

[0340] For example, the original resource associated with the transaction to be on-chain corresponds to 30; the transaction to be on-chain indicates that 20 resources in the original resource pool of object A are transferred to object B, then the target resource is 20 and the difference resource is 10. The first ticket is used to indicate that the resource pool of object B has 20 resources, and the second ticket is used to indicate that the resource pool of object A has 10 resources.

[0341] Please refer to Fig.19In one embodiment, the process of assigning an invalid flag to the bill associated with the transaction to be on-chain and adding the generated bill to the bill Merkle tree includes but is not limited to the following steps 1910-1920:

[0342] Step 1910: Generate a first bill based on the target resource, and generate a second bill based on the difference resource;

[0343] Step 1920: Add the first note and the second note to the bottom layer of the found note Merkle tree.

[0344] Steps 1910-1920 are described in detail below.

[0345] In step 1910, a first ticket is generated based on the target resource, and a second ticket is generated based on the difference resource.

[0346] In the specific implementation of this embodiment, the blockchain address storing the target resource and the blockchain address storing the difference resource are first determined. Then, a first bill is generated based on the target resource and the blockchain address storing the target resource. A second bill is generated based on the difference resource and the blockchain address storing the difference resource.

[0347] In step 1920, the first note and the second note are added to the lowest level in the found note Merkle tree.

[0348] In the specific implementation of this embodiment, first, the first bill and the second bill are used as new leaf nodes of the bill Merkle tree. Then, the leaf node corresponding to the first bill and the leaf node corresponding to the second bill are added to the lowest level of the found bill Merkle tree.

[0349] Furthermore, according to the predetermined index writing order, the first note and the second note are assigned note indexes, and the digest of the first note and the digest of the second note are calculated using the digest algorithm. Then, a higher-level feature is generated according to the digest of the first note and the digest of the second note, and so on, the root node of the note Merkle tree is updated.

[0350] like Fig. 20AAs shown. The target contract contains a bill Merkle tree and an invalid mark table. The Merkle tree contains 6 bills, namely Bill 1, Bill 2, Bill 3, Bill 4, Bill 5 and Bill 6. The summary 1 of Bill 1 and the summary 2 of Bill 2 are connected to generate the features of the previous layer, and the summary value 1 is obtained; the summary 3 of Bill 3 and the summary 4 of Bill 4 are connected to generate the features of the previous layer, and the summary value 2 is obtained; the summary 5 of Bill 5 and the summary 6 of Bill 6 are connected to generate the features of the previous layer, and the summary value 3 is obtained. Then, the summary value 1 and the summary value 2 are connected to generate the features of the next layer, and the summary value 5 is obtained, and the summary value 5 and the summary value 3 are connected to generate the features of the next layer, and the root node of the bill Merkle tree is obtained. In addition, the invalid mark table contains 3 invalid marks, namely invalid mark 1, invalid mark 2, and invalid mark 3. It can be seen that there are three invalid bills in the bill Merkle tree, but it is not certain which bill is invalid.

[0351] like Fig. 20B As shown in the figure, when a bill in the bill Merkle tree is used as a bill associated with a transaction to be on-chain, when the transaction to be on-chain is executed and the bill is consumed, the bill will become invalid and two new bills will be generated, namely, bill 7 and bill 8. Off-chain, the object will calculate an invalid mark 4 for the bill associated with the transaction to be on-chain, and the invalid mark 4 will be verified by the zero-knowledge circuit and a zero-knowledge proof will be issued. Further, after the zero-knowledge proof is successfully verified on-chain, the invalid mark 4 will be added to the invalid mark table, and bills 7 and 8 will be used as new nodes at the bottom layer of the bill Merkle tree. Further, bills 7 and 8 are assigned bill indexes and digests. Based on the digest 7 of bill 7 and the digest 8 of bill 8, the features of the previous layer are connected and generated to obtain a digest value 4; the digest value 3 and the digest value 4 are connected and generated to generate the features of the next layer to obtain a digest value 6; the digest value 5 and the digest value 6 are connected and generated to generate the root node of the bill Merkle tree, so as to realize the addition of nodes to the bill Merkle tree and the update of the digest value of the root node.

[0352] Through the above steps 1910-1920, the embodiment of the present disclosure splits the original resources corresponding to the bill associated with the transaction to be chained into target resources and difference resources according to the transaction to be chained, and generates a corresponding bill based on the target resource and the difference resource respectively, and records the two bills in the bill Merkle tree respectively, thereby realizing independent recording of the bills and eliminating the mutual influence of resources in each resource pool, thereby improving the security of transaction records.

[0353] Please refer to Fig.21 In one embodiment, after assigning an invalid flag to the bill associated with the transaction to be chained and adding the generated bill to the bill Merkle tree, the process of chaining the transaction to be chained includes but is not limited to the following steps 2110-2120:

[0354] Step 2110: Encrypt the first event of the invalid bill associated with the transaction to be put on the chain with the object public key corresponding to the object private key, and record it on the blockchain;

[0355] Step 2120: Generate the bill, encrypt it with the object public key, and record it on the blockchain.

[0356] Steps 2110-2120 are described in detail below.

[0357] In step 2110, the first event that the bill associated with the transaction to be on-chain is invalid is encrypted with the object public key corresponding to the object private key and recorded on the blockchain.

[0358] The first event that the ticket associated with the transaction to be put on the chain is invalid is used to indicate the specific content of the transaction to be put on the chain.

[0359] In the specific implementation of this embodiment, the object public key corresponding to the object private key is first obtained from the public platform. Then, the first event of invalidity of the bill associated with the transaction to be on the chain is encrypted with the object public key, and the encrypted first event is recorded on the blockchain.

[0360] In step 2120, the bill is generated, encrypted with the object's public key, and recorded on the blockchain.

[0361] In the specific implementation of this embodiment, the generated bill is first encrypted with the object public key to obtain the encrypted generated bill. Then, the encrypted generated bill is recorded on the blockchain.

[0362] Through the above steps 2110-2120, the embodiment of the present disclosure encrypts the first event of the invalid bill associated with the transaction to be on the chain and the generated bill using the object public key corresponding to the object private key, and records the encrypted first event and the generated bill on the blockchain, so that the first event and the generated bill on the blockchain can only be decrypted using the object private key, which can improve the on-chain security of the first event and the generated bill, and also ensure that the zero-knowledge proof generated by the object for the transaction to be on the chain off-chain and the first event and the invalid mark recorded on the blockchain have good consistency.

[0363] Detailed description of a transaction processing operation on an object terminal according to an embodiment of the present disclosure

[0364] In order to perform pairing operations with the target contract provided on the blockchain and implement a transaction on-chain processing solution that combines on-chain and off-chain, the embodiment of the present disclosure provides a terminal for providing an object with off-chain operations, and the terminal includes a first content page. The terminal refers to a client that can provide security for transaction on-chain processing.

[0365] Please refer to Fig. 22, is a data structure diagram used in the object terminal to implement resource processing off-chain. Specifically, the first content page of the object terminal displays a resource access module, a resource transfer module, a resource status dashboard, a zero-knowledge circuit execution module, and a key storage space. Among them, the resource access module is used for the object to store the public virtual resources into the target contract of the blockchain, and the resource access module is also used to transfer the virtual resources in the target contract to other public resource pools. The key storage space is used to store multiple public and private key pairs issued by the relevant certification authority to the object, wherein the public and private key pairs refer to the one-to-one corresponding object public key and object private key. The resource status dashboard is used to provide the object with the resources of the object on the target contract, as well as the object's multiple transaction processing records based on the target contract. The zero-knowledge circuit execution module is used to provide the object with verification of relevant information through the zero-knowledge circuit and generate zero-knowledge proof. The resource transfer module is used to provide the object with resource transfer for multiple resources of the target contract.

[0366] Please refer to Fig.23 In one embodiment, the process of obtaining the object identity information, the Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed includes but is not limited to the following steps 2310-2330:

[0367] Step 2310: display the first content page;

[0368] Step 2320: In response to the selection operation of the zero-knowledge circuit execution module in the first content page, display the second content page;

[0369] Step 2330: In response to the input operation on the second content page, obtain the object identity information, the Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed.

[0370] Steps 2310-2330 are described in detail below.

[0371] In step 2310, a first content page is displayed.

[0372] In the specific implementation of this embodiment, when the object needs to perform transaction processing, the object will interact with the object terminal, so that the first content page is displayed on the front-end interface of the object terminal, so as to perform the corresponding transaction processing operation through the first content page. Based on this, when the interactive operation of the object is received, the first content page is displayed.

[0373] In step 2320 , in response to a selection operation on a zero-knowledge circuit execution module in the first content page, a second content page is displayed.

[0374] The second content page is used to provide an input area for relevant information used to generate zero-knowledge proof.

[0375] In the specific implementation of this embodiment, when the object wants to obtain the zero-knowledge proof, the object will select the zero-knowledge circuit execution module in the first content page to execute the zero-knowledge proof generation process through the zero-knowledge circuit execution module. Based on this, when the selection operation of the zero-knowledge circuit execution module is received, the second content page is displayed.

[0376] In step 2330, in response to the input operation on the second content page, the object identity information, the Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed are obtained.

[0377] In the specific implementation of this embodiment, after the object enters relevant information that needs to be verified by the zero-knowledge circuit in the second content page, the server will receive the object's input operation on the second content page, and determine the object's identity information, Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed from the input relevant information.

[0378] like Fig.24A As shown, after the object selects the zero-knowledge circuit execution module in the first content page, the second content page is displayed on the object terminal. The second content page contains an input area corresponding to the object private key, an input area corresponding to the Merkle tree proof, an input area corresponding to the relevant information for generating bills, an input area corresponding to the root summary of the bill Merkle tree, and an input area corresponding to the invalid mark. At this time, the object enters the object private key "Xxxx" determined from the key storage space in the input area corresponding to the object private key; enters "Xxxx1" in the input area corresponding to the Merkle tree proof; enters "Xxxx111" in the input area corresponding to the relevant information for generating bills; enters "Qweqa13" in the input area corresponding to the root summary of the bill Merkle tree; and enters "Invalid mark 3" in the input area corresponding to the invalid mark. After entering all the information, the object clicks the "OK" button to verify the information through the zero-knowledge circuit and generate a zero-knowledge proof.

[0379] like Fig. 24B As shown, when the server receives the object identity information, Merkle tree proof, and the generated bill after the transaction to be on-chain is executed, and verifies all the information successfully, it generates a zero-knowledge proof through the zero-knowledge circuit. At this time, a prompt field "The information you provided has been verified, and the zero-knowledge proof K has been generated. The storage location of the zero-knowledge proof K is xxx / d" will be displayed on the second content page.

[0380] Through the above steps 2310-2330, in the embodiment of the present disclosure, the object can verify various information through the zero-knowledge circuit execution module in the object terminal and generate corresponding zero-knowledge proofs, so that the zero-knowledge proofs can be used for transaction chain records, realize accurate verification before chaining, and improve the security of transaction chaining.

[0381] Please refer to Fig.25 In one embodiment, after displaying the first content page, the transaction on-chain processing method further includes but is not limited to the following steps 2510-2530:

[0382] Step 2510: In response to a selection operation on a resource transfer module in the first content page, display a third content page;

[0383] Step 2520: In response to the zero-knowledge proof input operation in the third content page, determine the zero-knowledge proof for resource transfer;

[0384] Step 2530: In response to the resource transfer operation in the third content page, based on the zero-knowledge proof, execute the resource transfer transaction, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated ticket of the resource transfer transaction and adds the generated ticket to the ticket Merkle tree.

[0385] Steps 2510-2530 are described in detail below.

[0386] In step 2510, in response to a selection operation on a resource transfer module in the first content page, a third content page is displayed.

[0387] The second content page is used to provide an input area for relevant information used to implement the resource transfer transaction.

[0388] In the specific implementation of this embodiment, when the object wants to perform a resource transfer operation, the object will select the resource transfer module in the first content page to execute the resource transfer process through the resource transfer module. Based on this, when the selection operation of the resource transfer module is received, the third content page is displayed.

[0389] In step 2520 , in response to a zero-knowledge proof input operation in the third content page, a zero-knowledge proof for resource transfer is determined.

[0390] In the specific implementation of this embodiment, when the object wants to perform a resource transfer transaction, it needs to provide a zero-knowledge proof. Based on this, the object will enter a storage location of a zero-knowledge proof in the third content page to call the corresponding zero-knowledge proof. Therefore, the server will respond to the zero-knowledge proof input operation in the third content page and determine the zero-knowledge proof for resource transfer.

[0391] Furthermore, the third content page may also provide an input area for other related information to receive other public information input by the subject in the third content page.

[0392] In step 2530, in response to the resource transfer operation in the third content page, a resource transfer transaction is executed based on zero-knowledge proof, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated ticket of the resource transfer transaction and adds the generated ticket to the ticket Merkle tree.

[0393] In the specific implementation of this embodiment, when the object enters the zero-knowledge proof and related information on the third content page and chooses to perform the resource transfer operation, the server will receive the resource transfer operation of the object in the third content page, and will perform the resource transfer transaction based on the zero-knowledge proof, and provide the resource transfer transaction to the consensus node. After the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated bill of the resource transfer transaction, and adds a generated bill to the bill Merkle tree. The specific implementation process is similar to the specific implementation process of the above step 330. To save space, it will not be repeated.

[0394] like Fig.26A As shown, after the object selects the resource transfer module in the first content page, the third content page is displayed on the object terminal. The third content page contains an input area corresponding to the zero-knowledge proof, an input area corresponding to the relevant information for generating the bill, an input area corresponding to the root summary of the bill Merkle tree, and an input area corresponding to the invalid mark. At this time, the object enters "zero-knowledge proof M" in the input area corresponding to the zero-knowledge proof; enters "Xxxx23" in the input area corresponding to the relevant information for generating the bill; enters "Qweqa13" in the input area corresponding to the root summary of the bill Merkle tree; enters "Invalid mark 1" in the input area corresponding to the invalid mark. After entering all the information, the object clicks the "OK" button to submit the aforementioned information to the chain.

[0395] like Fig.26B As shown, after the server receives the various information entered by the object on the third content page, it will verify the zero-knowledge proof M, and after the zero-knowledge proof M is successfully verified, it will execute the corresponding resource transfer transaction based on the consensus node on the blockchain, assign an invalid mark to the associated bill of the resource transfer transaction, and add a generated bill to the bill Merkle tree. At this time, a prompt field "The zero-knowledge proof M you provided has been verified, and an invalid mark has been assigned to the associated bill of the resource transfer transaction, and a new generated bill has been added to the bill Merkle tree" will be displayed on the third content page.

[0396] Through the above steps 2510-2530, in the embodiment of the present disclosure, the object can implement the resource transfer operation on the on-chain resources through the resource transfer module in the object terminal, and improve the security of the execution of the resource transfer transaction by providing the zero-knowledge proof and related public information generated off-chain.

[0397] Please refer to Fig. 27 In one embodiment, after displaying the first content page, the transaction on-chain processing method further includes but is not limited to the following steps 2710-2730:

[0398] Step 2710: In response to a selection operation on a resource transfer module in the first content page, display a third content page;

[0399] Step 2720: In response to the zero-knowledge proof input operation in the third content page, determine the zero-knowledge proof for resource extraction;

[0400] Step 2730: In response to the resource extraction operation in the third content page, based on the zero-knowledge proof, execute the resource extraction transaction, so that the consensus node assigns an invalid mark to the associated ticket of the resource extraction transaction after the zero-knowledge proof is successfully verified.

[0401] Steps 2710-2730 are described in detail below.

[0402] In step 2710, in response to a selection operation on a resource transfer module in the first content page, a third content page is displayed.

[0403] When this embodiment is implemented, the specific implementation process of step 2710 is similar to the specific implementation process of the above step 2510. To save space, it will not be repeated.

[0404] In step 2720 , in response to a zero-knowledge proof input operation in the third content page, a zero-knowledge proof for resource extraction is determined.

[0405] When this embodiment is implemented, the specific implementation process of step 2720 is similar to the specific implementation process of step 2520. The difference is that the zero-knowledge proof of step 2520 is used to prove that the object has the operation authority to perform the resource transfer operation, and is used to indicate the specific content of the resource transfer operation; while the zero-knowledge proof of step 2720 is used to prove that the object has the operation authority to perform the resource extraction operation, and is used to indicate the specific content of the resource extraction operation. The functions and contents of the zero-knowledge proofs of the two are different. To save space, they will not be repeated.

[0406] In step 2730, in response to the resource extraction operation in the third content page, a resource extraction transaction is performed based on the zero-knowledge proof, so that the consensus node assigns an invalid flag to the associated ticket of the resource extraction transaction after the zero-knowledge proof is successfully verified.

[0407] When this embodiment is specifically implemented, the specific implementation process of step 2730 is similar to the specific implementation process of step 2530 mentioned above. The difference is that after the execution of step 2530, an invalid mark of the associated bill of the resource transfer transaction will be generated, and a new bill will be generated that needs to be recorded in the bill Merkle tree. After the execution of step 2730, an invalid mark of the associated bill of the resource extraction transaction will be generated, and no new bill will be generated. It is the extraction of all resources associated with the bill of the resource extraction transaction. The results of the two transactions after execution are different. In order to save space, it will not be repeated.

[0408] like Fig.28A As shown, after the object selects the resource transfer module in the first content page, the third content page is displayed on the object terminal. The third content page contains an input area corresponding to the zero-knowledge proof, an input area corresponding to the root summary of the bill Merkle tree, and an input area corresponding to the invalid mark. At this time, the object enters "zero-knowledge proof J" in the input area corresponding to the zero-knowledge proof; enters "Qweqa13" in the input area corresponding to the root summary of the bill Merkle tree; and enters "invalid mark 5" in the input area corresponding to the invalid mark. After entering all the information, the object clicks the "OK" button to submit the aforementioned information to the chain.

[0409] like Fig.28B As shown, after the server receives the various information entered by the subject on the third content page, it will verify the zero-knowledge proof J, and after the zero-knowledge proof J is successfully verified, it will execute the corresponding resource extraction transaction based on the consensus node on the blockchain, and assign an invalid mark to the associated ticket of the resource extraction transaction. At this time, a prompt field "The zero-knowledge proof J you provided has been verified and the associated ticket of the resource extraction transaction has been assigned an invalid mark" will be displayed on the third content page.

[0410] Through the above steps 2710-2730, in the embodiment of the present disclosure, the object can implement resource extraction operations on on-chain resources through the resource transfer module in the object terminal, and improve the security of on-chain resource extraction by providing zero-knowledge proofs and related public information generated off-chain.

[0411] Please refer to Fig.29 In one embodiment, after displaying the first content page, the transaction on-chain processing method further includes but is not limited to the following steps 2910-2920:

[0412] Step 2910: In response to a selection operation on a resource access module in the first content page, display a fourth content page;

[0413] Step 2920: In response to the resource deposit operation in the fourth content page, generate a new ticket, and add the new ticket to the bottom layer of the ticket Merkle tree.

[0414] Steps 2910-2920 are described in detail below.

[0415] In step 2910 , in response to a selection operation on a resource access module in the first content page, a fourth content page is displayed.

[0416] The fourth content page is used to provide selectable resource deposit controls and resource retrieval controls.

[0417] In the specific implementation of this embodiment, when the object wants to store a virtual resource in the blockchain, or the object wants to extract a virtual resource from the blockchain, the object will select the resource access module in the first content page to enter the resource access process. At this time, the server will receive the object's selection operation on the resource access module in the first content page, and in response to the selection operation, display the fourth content page corresponding to the resource access module.

[0418] In step 2920, in response to the resource deposit operation in the fourth content page, a new ticket is generated, and the new ticket is added to the bottom layer of the ticket Merkle tree.

[0419] In the specific implementation of this embodiment, when the fourth content page is displayed, if the object wants to deposit a virtual resource into the blockchain, the object will interact with the resource deposit control in the fourth content page to execute the resource deposit process. At this time, the server will receive the resource deposit operation of the object in the fourth content page, convert the public virtual resource selected by the object into a private virtual resource, and generate a new ticket for the converted private virtual resource record, and add the new ticket to the bottom layer of the ticket Merkle tree.

[0420] like Fig. 30A As shown, when the object selects the resource access module in the first content page, the fourth content page is displayed, wherein the fourth content page displays a prompt field "Please select the following controls to perform the corresponding process", as well as interactive resource deposit controls and resource withdrawal controls. At this time, the object selects the resource deposit control to execute the resource deposit process.

[0421] like Fig. 30BAs shown, after the object selects the resource to be stored in the control, a prompt field "Please enter the virtual resources to be stored" and an input area for entering the number of selected public virtual resources will be displayed in the fourth content page. At this time, the object enters "200" in the input area and clicks the "OK" button to convert the 200 public virtual resources into private virtual resources. After the server receives the input operation of the object, it will add a new ticket at the bottom layer of the ticket Merkle tree, which is used to indicate that the resource address of the object stores 200 virtual resources.

[0422] Through the above steps 2910-2920, the embodiment of the disclosure realizes converting the public virtual resources into virtual resources with better confidentiality through the resource access module in the object terminal, and adding the tickets corresponding to the virtual resources with better confidentiality in the ticket Merkle tree. At the same time, the resource access module can also realize extracting the virtual resources in a confidential state into the public resource pool to improve the access security of the virtual resources.

[0423] Detailed description of the implementation of a transaction on-chain processing method of an embodiment of the present disclosure

[0424] Combine the following Fig.31A ,and Fig.31B The implementation details of the transaction on-chain processing method of the embodiment of the present disclosure are described in detail.

[0425] like Fig.31A As shown, the transaction chain processing method of the disclosed embodiment is jointly implemented by the target contract on the blockchain and the object terminal under the blockchain. On the one hand, in the private server of the object under the blockchain, the object is enabled to operate private resources based on the object terminal. The object terminal provides key storage space, zero-knowledge circuit execution module, etc. to realize the verification of the operation authority and operation content of the object, and realize the transaction verification before chaining. This process is similar to the specific implementation process of the above steps 310-320. On the other hand, on the blockchain, the target contract in the blockchain verifies the zero-knowledge proof and related information submitted to the chain, so that after the zero-knowledge proof is successfully verified, the target contract is used to assign an invalid mark to the bill associated with the transaction to be chained based on the target contract, and a new generated bill is added to the bill Merkel tree maintained by the target contract to synchronize the latest status. Its specific implementation process is similar to the specific implementation process of step 330 above.

[0426] like Fig.31B As shown, the target contract maintains a bill Merkle tree, multiple invalid flags, and a record of inserted bills. When the object transfers resources through the resource access module of the object terminal under the blockchain, the target contract will execute the resource deposit process and add the bills associated with the deposited resources to the bill Merkle tree. The specific implementation process is similar to the specific implementation process of the above steps 2910-2920.

[0427] Furthermore, when the object performs a resource processing operation through the resource transfer module of the object terminal under the blockchain, the object generates a zero-knowledge proof through the zero-knowledge circuit execution module, and its specific implementation process is similar to the specific implementation process of the above steps 310-320.

[0428] After the object provides the zero-knowledge proof on the chain, the object can execute resource transfer transactions and resource extraction transactions according to the target contract. Among them, when executing the resource transfer transaction, the target contract will add the generated bill to the bottom layer of the bill Merkle tree, and record the invalid flag assigned to the bill associated with the transaction to be on the chain into the invalid flag management table. The specific implementation process is similar to the specific implementation process of the above steps 2510-2530.

[0429] When executing a resource extraction transaction, the target contract will record the invalid mark assigned to the ticket associated with the transaction to be on-chain into the invalid mark management table, and its specific implementation process is similar to the specific implementation process of the above steps 2710-2730.

[0430] Description of the apparatus and device of the present disclosure

[0431] It is to be understood that, although the steps in the above-mentioned flowcharts are sequentially displayed according to the characterization of arrows, these steps are not necessarily executed in sequence according to the order of arrow characterization. Unless there is a clear description in the present embodiment, the execution of these steps does not have a strict order restriction, and these steps can be executed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts can include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of the steps or stages in other steps.

[0432] It should be noted that in each specific implementation of the present application, when it comes to the need to perform relevant processing based on data related to the characteristics of the target object such as the target object attribute information or attribute information set, the permission or consent of the target object will be obtained first, and the collection, use and processing of these data will comply with relevant laws, regulations and standards. In addition, when the embodiment of the present application needs to obtain the attribute information of the target object, the separate permission or separate consent of the target object will be obtained through a pop-up window or jump to a confirmation page. After clearly obtaining the separate permission or separate consent of the target object, the necessary target object-related data used to enable the normal operation of the embodiment of the present application is obtained.

[0433] Fig.32A schematic diagram of the structure of a transaction on-chain processing device 3200 provided in an embodiment of the present disclosure. The transaction on-chain processing device 3200 includes:

[0434] The acquisition unit 3210 is used to acquire the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed;

[0435] A generating unit 3220, configured to verify the object identity information, the Merkle tree proof, and the generation ticket, and generate a zero-knowledge proof based on the object identity information, the Merkle tree proof, and the generation ticket through a zero-knowledge circuit after successful verification;

[0436] The sending unit 3230 is used to send the zero-knowledge proof to the consensus node, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on the chain, and adds the generated bill to the bill Merkle tree.

[0437] Optionally, the sending unit 3230 is specifically configured to:

[0438] Add the invalid flag assigned to the ticket associated with the transaction to be on-chain to the target contract;

[0439] Find the bill Merkle tree in the target contract;

[0440] At the bottom level of the Merkle tree of the found bills, add the generated bill.

[0441] Optionally, the object identity information includes an object private key;

[0442] The transaction on-chain processing device 3200 further includes an on-chain unit (not shown), which is used to:

[0443] The first event of invalidation of the bill associated with the transaction to be put on the chain is encrypted with the object public key corresponding to the object private key and recorded on the blockchain;

[0444] The bill will be generated, encrypted with the object's public key, and recorded on the blockchain.

[0445] Optionally, the transaction to be chained and associated with the bill corresponds to the original resource, and the transaction to be chained is a resource transfer transaction for transferring the target resource from the original resource; the generated bill includes a first bill and a second bill, the first bill corresponds to the target resource, and the second bill corresponds to the difference resource between the original resource and the target resource;

[0446] At the bottom level of the Merkle tree of the found bill, add the generated bill, including:

[0447] Generate a first note based on the target resource and generate a second note based on the difference resource;

[0448] At the bottom layer of the Merkle tree of the found bills, add the first bill and the second bill.

[0449] Optionally, the generating unit 3220 further includes:

[0450] A first verification unit (not shown), configured to perform a first verification based on the object identity information and the ticket associated with the transaction to be uploaded to the chain;

[0451] A second verification unit (not shown), configured to perform a second verification on the bill associated with the transaction to be on-chain based on the Merkle tree proof if the first verification is determined to be passed;

[0452] A third verification unit (not shown), configured to perform a third verification on the invalidation flag assigned to the ticket associated with the transaction to be on-chained if it is determined that the second verification is passed;

[0453] a fourth verification unit (not shown), configured to perform a fourth verification on the generated ticket if it is determined that the third verification passes;

[0454] A determination unit (not shown) is configured to determine that the verification is successful if it is determined that the fourth verification is passed.

[0455] Optionally, the first verification unit (not shown) is specifically used for:

[0456] Perform a digest operation on the object private key in the object identity information to obtain an object digest value;

[0457] If the object summary value is consistent with the ticket associated with the transaction to be on-chain, the first verification is determined to be successful;

[0458] If the object summary value is inconsistent with the ticket associated with the transaction to be on-chain, it is determined that the first verification fails.

[0459] Optionally, the Merkle tree proof includes the bypass note index of the note associated with the transaction to be on-chain in the note Merkle tree, and the bypass note summary value;

[0460] The second verification unit (not shown) is specifically used for:

[0461] Determine the bill summary value of the bill associated with the transaction to be on-chain in the bill Merkle tree;

[0462] Calculate the digest of the root node to be verified of the bill Merkle tree based on the bill digest value, the bypass bill index and the bypass bill digest value;

[0463] If it is determined that the root node digest to be verified is consistent with the public root node digest, then it is determined that the second verification is passed;

[0464] If it is determined that the root node digest to be verified is inconsistent with the public root node digest, it is determined that the second verification fails.

[0465] Optionally, the third verification unit (not shown) is specifically used for:

[0466] For the bills associated with the transactions to be put on the chain, based on the object identity information and the Merkle tree proof, a target invalidation mark is generated for the bills associated with the transactions to be put on the chain;

[0467] If it is determined that the target invalid mark and the invalid mark are consistent, it is determined that the third verification is passed;

[0468] If it is determined that the target invalid flag and the invalid flag are inconsistent, it is determined that the third verification fails.

[0469] Optionally, the target invalidation flag is generated by:

[0470] Extract the bypass note index of the note associated with the transaction to be on-chain from the Merkle tree proof;

[0471] Concatenate the object private key and the bypass ticket index in the object identity information to obtain a concatenation result;

[0472] Perform a digest operation on the concatenation result to obtain the target invalidation mark.

[0473] Optionally, the generated note contains multiple sub-notes;

[0474] The fourth verification unit (not shown) is specifically used for:

[0475] Integrate the resources indicated by the multiple sub-notes to obtain a first resource;

[0476] If it is determined that the first resource is consistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification is passed;

[0477] If it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification fails.

[0478] Optionally, the fourth verification unit (not shown) is specifically used for:

[0479] Get the blockchain address associated with the generated note;

[0480] Perform address verification on blockchain addresses;

[0481] If it is determined that the blockchain address verification has passed, then it is determined that the fourth verification has passed.

[0482] Optionally, the fourth verification unit (not shown) is specifically used for:

[0483] Determine a first resource amount associated with the generated ticket and a second resource amount associated with the ticket associated with the transaction to be uploaded to the chain;

[0484] If it is determined that the first resource amount is less than or equal to the second resource amount, it is determined that the fourth verification is passed.

[0485] Optionally, the acquiring unit 3210 is used to:

[0486] Display the first content page;

[0487] In response to a selection operation on the zero-knowledge circuit execution module in the first content page, displaying a second content page;

[0488] In response to the input operation on the second content page, object identity information, Merkle tree proof, and a generated ticket after the transaction to be on-chain is executed are obtained.

[0489] Optionally, the transaction on-chain processing device 3200 further includes a first processing unit (not shown), and the first processing unit (not shown) is used to:

[0490] In response to a selection operation on the resource transfer module in the first content page, displaying a third content page;

[0491] In response to a zero-knowledge proof input operation in the third content page, determining a zero-knowledge proof for resource transfer;

[0492] In response to the resource transfer operation in the third content page, a resource transfer transaction is executed based on zero-knowledge proof, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated ticket of the resource transfer transaction and adds a generated ticket to the ticket Merkle tree.

[0493] Optionally, the transaction on-chain processing device 3200 further includes a second processing unit (not shown), and the second processing unit (not shown) is used to:

[0494] In response to a selection operation on the resource transfer module in the first content page, displaying a third content page;

[0495] In response to a zero-knowledge proof input operation in a third content page, determining a zero-knowledge proof for resource extraction;

[0496] In response to the resource extraction operation in the third content page, based on the zero-knowledge proof, a resource extraction transaction is executed so that the consensus node assigns an invalidation mark to the associated ticket of the resource extraction transaction after the zero-knowledge proof is successfully verified.

[0497] Optionally, the transaction on-chain processing device 3200 further includes a third processing unit (not shown), and the third processing unit (not shown) is used to:

[0498] In response to a selection operation on a resource access module in the first content page, displaying a fourth content page;

[0499] In response to the resource deposit operation in the fourth content page, a new ticket is generated, and the new ticket is added to the bottom layer of the ticket Merkle tree.

[0500] Reference Fig.33 , Fig.33 The structural block diagram of the terminal part for implementing the transaction on-chain processing method of the embodiment of the present disclosure includes: Radio Frequency (RF) circuit 3310, memory 3315, input unit 3330, display unit 3340, sensor 3350, audio circuit 3360, wireless fidelity (WiFi) module 3370, processor 3380, power supply 3390 and other components. Those skilled in the art can understand that Fig.33 The terminal structure shown does not constitute a limitation on the mobile phone or computer, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0501] The RF circuit 3310 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information from the base station, it is sent to the processor 3380 for processing; in addition, the designed uplink data is sent to the base station.

[0502] The memory 3315 may be used to store software programs and modules. The processor 3380 executes various functional applications and data processing of the target terminal by running the software programs and modules stored in the memory 3315 .

[0503] The input unit 3330 may be used to receive input digital or character information and generate key signal input related to the setting and function control of the target terminal. Specifically, the input unit 3330 may include a touch panel 3331 and other input devices 3332.

[0504] The display unit 3340 may be used to display input information or provided information and various menus of the target terminal. The display unit 3340 may include a display panel 3341.

[0505] The audio circuit 3360, the speaker 3361, and the microphone 3362 may provide an audio interface.

[0506] In this embodiment, the processor 3380 included in the terminal can execute the transaction on-chain processing method of the previous embodiment.

[0507] The terminals of the embodiments of the present disclosure include but are not limited to mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, aircraft, etc. The embodiments of the present invention can be applied to various scenarios, including but not limited to data security, blockchain, data storage, information technology, etc.

[0508] Fig.34 A block diagram of the structure of a portion of a server for implementing the transaction chain processing method of an embodiment of the present disclosure. The server may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPUs) 3422 (for example, one or more processors) and memories 3432, and one or more storage media 3430 (for example, one or more mass storage devices) storing application programs 3442 or data 3444. Among them, the memory 3432 and the storage medium 3430 can be short-term storage or permanent storage. The program stored in the storage medium 3430 may include one or more modules (not shown in the figure), and each module may include a series of instruction operations on the server. Furthermore, the central processing unit 3422 can be configured to communicate with the storage medium 3430 and execute a series of instruction operations in the storage medium 3430 on the server.

[0509] The server may also include one or more power supplies 3434, one or more wired or wireless network interfaces 3450, one or more input and output interfaces 3458, and / or, one or more operating systems 3441, such as Windows ServerTM, Mac OS XTM, UnixTM, LinuxTM, FreeBSDTM, etc.

[0510] The central processor 3422 in the server can be used to execute the transaction chain processing method of the embodiment of the present disclosure.

[0511] The embodiments of the present disclosure also provide a computer-readable storage medium, which is used to store program code, and the program code is used to execute the transaction chain processing method of each of the aforementioned embodiments.

[0512] The embodiment of the present disclosure also provides 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 executes and implements the transaction on-chain processing method.

[0513] The terms "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 are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present disclosure described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "comprises" and "comprising" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0514] In the embodiments of the present disclosure, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0515] It should be understood that in the present disclosure, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least 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.

[0516] It should be understood that in the description of the embodiments of the present disclosure, the meaning of multiple (or multiple items) is more than two, greater than, less than, exceed, etc. are understood to not include the number, and above, below, within, etc. are understood to include the number.

[0517] In the several embodiments provided in 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 schematic. For example, the division of units is only a logical function division. There may be other division methods in actual implementation. 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 mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0518] 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 on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0519] In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0520] 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 is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the various embodiments of the present disclosure. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, referred to as ROM), random access memory (Random Access Memory, referred to as RAM), disk or optical disk and other media that can store program codes.

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

[0522] The above is a specific description of the implementation methods of the present disclosure, but the present disclosure is not limited to the above implementation methods. Technical personnel familiar with the art can also make various equivalent modifications or substitutions without violating the spirit of the present disclosure. These equivalent modifications or substitutions are all included in the scope defined by the claims of the present disclosure.

Claims

1. A transaction on-chain processing method, It is characterized in that include: Obtain the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed; Verifying the object identity information, the Merkle tree proof, and the generated note, and generating a zero-knowledge proof based on the object identity information, the Merkle tree proof, and the generated note through a zero-knowledge circuit after the verification is successful; The zero-knowledge proof is sent to a consensus node so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

2. The transaction on-chain processing method according to claim 1, It is characterized in that The step of assigning an invalid mark to the transaction-associated note to be put on the chain, and adding the generated note to the note Merkle tree, includes: Add the invalid flag assigned to the ticket associated with the transaction to be on-chain to the target contract; Searching for the bill Merkle tree in the target contract; At the bottom layer of the found bill Merkle tree, add the generated bill.

3. The transaction on-chain processing method according to claim 2, It is characterized in that The object identity information includes an object private key; After adding the generated bill to the lowest level of the bill Merkle tree found, the transaction on-chain processing method further includes: The first event that the bill associated with the transaction to be put on the chain is invalid is encrypted with the object public key corresponding to the object private key, and recorded on the blockchain; The generated note is encrypted with the object public key and recorded on the blockchain.

4. The transaction on-chain processing method according to claim 2, It is characterized in that The transaction-associated note to be on-chain corresponds to the original resource, and the transaction to be on-chain is a resource transfer transaction that transfers the target resource from the original resource; the generated note includes a first note and a second note, the first note corresponds to the target resource, and the second note corresponds to the difference resource between the original resource and the target resource; The step of adding the generated bill to the lowest level of the bill Merkle tree found includes: generating the first bill based on the target resource, and generating the second bill based on the difference resource; At the bottom layer of the found bill Merkle tree, add the first bill and the second bill.

5. The transaction on-chain processing method according to claim 1, It is characterized in that The verifying of the object identity information, the Merkle tree proof and the generated ticket includes: Perform a first verification based on the object identity information and the ticket associated with the transaction to be on-chain; If it is determined that the first verification is passed, a second verification is performed on the ticket associated with the transaction to be on-chain based on the Merkle tree proof; If it is determined that the second verification is passed, a third verification is performed on the invalidation mark assigned to the ticket associated with the transaction to be on-chain; If it is determined that the third verification passes, performing a fourth verification on the generated ticket; If it is determined that the fourth verification is passed, it is determined that the verification is successful.

6. The transaction on-chain processing method according to claim 5, It is characterized in that The first verification based on the object identity information and the ticket associated with the transaction to be on-chain includes: Performing a digest operation on the object private key in the object identity information to obtain an object digest value; If the object summary value is consistent with the transaction-associated ticket to be on-chained, it is determined that the first verification is passed; If the object summary value is inconsistent with the transaction-associated ticket to be on-chained, it is determined that the first verification fails.

7. The transaction on-chain processing method according to claim 5, It is characterized in that The Merkle tree proof includes the bypass note index of the note associated with the transaction to be on-chain in the note Merkle tree, and the bypass note summary value; The second verification of the transaction-associated bill to be put on the chain based on the Merkle tree proof includes: Determine the bill summary value of the bill associated with the transaction to be on-chain in the bill Merkle tree; Calculate the to-be-verified root node digest of the bill Merkle tree based on the bill digest value, the bypass bill index, and the bypass bill digest value; If it is determined that the to-be-verified root node digest is consistent with the public root node digest, then it is determined that the second verification is passed; If it is determined that the to-be-verified root node digest is inconsistent with the public root node digest, it is determined that the second verification fails.

8. The transaction on-chain processing method according to claim 5, It is characterized in that The third verification of the invalidation mark assigned to the ticket associated with the transaction to be on-chain includes: For the transaction-associated ticket to be put on the chain, based on the object identity information and the Merkle tree proof, generate a target invalidation mark for the transaction-associated ticket to be put on the chain; If it is determined that the target invalid mark is consistent with the invalid mark, then it is determined that the third verification is passed; If it is determined that the target invalidation flag and the invalidation flag are inconsistent, it is determined that the third verification fails.

9. The transaction on-chain processing method according to claim 8, It is characterized in that The target invalid flag is generated in the following way: Extracting the bypass note index of the note associated with the transaction to be on-chain from the Merkle tree proof; Concatenate the object private key in the object identity information and the bypass ticket index to obtain a concatenation result; A digest operation is performed on the concatenation result to obtain the target invalidation mark.

10. The transaction on-chain processing method according to claim 5, It is characterized in that The generated note includes a plurality of sub-notes; The performing a fourth verification on the generated bill includes: Integrate the resources indicated by the plurality of sub-tickets to obtain a first resource; If it is determined that the first resource is consistent with the second resource indicated by the transaction-associated ticket to be on-chained, then it is determined that the fourth verification is passed; If it is determined that the first resource is inconsistent with the second resource indicated by the ticket associated with the transaction to be on-chain, it is determined that the fourth verification fails.

11. The transaction on-chain processing method according to claim 5, It is characterized in that The performing a fourth verification on the generated bill includes: Obtaining the blockchain address associated with the generated bill; Performing address verification on the blockchain address; If it is determined that the blockchain address verification is passed, then it is determined that the fourth verification is passed.

12. The transaction on-chain processing method according to claim 5, It is characterized in that The performing a fourth verification on the generated bill includes: Determine a first resource amount associated with the generated ticket and a second resource amount associated with the ticket associated with the transaction to be uploaded to the chain; If it is determined that the first resource amount is less than or equal to the second resource amount, it is determined that the fourth verification is passed.

13. The transaction on-chain processing method according to claim 1, It is characterized in that The acquisition of the object identity information, the Merkle tree proof of the bill associated with the transaction to be on-chain on the bill Merkle tree, and the generated bill after the transaction to be on-chain is executed include: Display the first content page; In response to a selection operation on the zero-knowledge circuit execution module in the first content page, displaying a second content page; In response to an input operation on the second content page, the object identity information, the Merkle tree proof, and the generated ticket after the transaction to be on-chain is executed are obtained.

14. The transaction on-chain processing method according to claim 13, It is characterized in that After displaying the first content page, the method further includes: In response to a selection operation on a resource transfer module in the first content page, displaying a third content page; In response to a zero-knowledge proof input operation in the third content page, determining a zero-knowledge proof for resource transfer; In response to the resource transfer operation in the third content page, a resource transfer transaction is executed based on the zero-knowledge proof, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the associated ticket of the resource transfer transaction and adds a generated ticket to the ticket Merkle tree.

15. The transaction on-chain processing method according to claim 13, It is characterized in that After displaying the first content page, the method further includes: In response to a selection operation on a resource transfer module in the first content page, displaying a third content page; In response to a zero-knowledge proof input operation in the third content page, determining a zero-knowledge proof for resource extraction; In response to a resource extraction operation in the third content page, a resource extraction transaction is performed based on the zero-knowledge proof, so that the consensus node assigns an invalidation mark to an associated ticket of the resource extraction transaction after the zero-knowledge proof is successfully verified.

16. The transaction on-chain processing method according to claim 13, It is characterized in that After displaying the first content page, the method further includes: In response to a selection operation on a resource access module in the first content page, displaying a fourth content page; In response to the resource deposit operation in the fourth content page, a new ticket is generated, and the new ticket is added to the bottom layer of the ticket Merkle tree.

17. A transaction on-chain processing device, It is characterized in that The transaction on-chain processing device comprises: An acquisition unit, used to acquire object identity information, a Merkle tree certificate of the bill associated with the transaction to be on-chain on the bill Merkle tree, and a generated bill after the transaction to be on-chain is executed; A generating unit, configured to verify the object identity information, the Merkle tree proof and the generated note, and generate a zero-knowledge proof based on the object identity information, the Merkle tree proof and the generated note through a zero-knowledge circuit after the verification is successful; A sending unit is used to send the zero-knowledge proof to a consensus node, so that after the zero-knowledge proof is successfully verified, the consensus node assigns an invalid mark to the bill associated with the transaction to be on-chain, and adds the generated bill to the bill Merkle tree.

18. An electronic device comprising a memory and a processor, wherein the memory stores a computer program. It is characterized in that When the processor executes the computer program, the transaction on-chain processing method described in any one of claims 1 to 16 is implemented.

19. A computer-readable storage medium storing a computer program. It is characterized in that When the computer program is executed by a processor, the transaction on-chain processing method described in any one of claims 1 to 16 is implemented.

20. 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 transaction on-chain processing method described in any one of claims 1 to 16.

Images