Check transaction data processing method and device based on block chain, and electronic equipment

Abstract

The invention discloses a check transaction data processing method and device based on a block chain and electronic equipment, and relates to the technical field of block chains and the field of financial science and technology. The method comprises the following steps: receiving check transaction data uploaded by an application server through a block chain node server of a target financial institution; generating a binary tree sharing path according to the check transaction data; according to the scene identifier on the block chain and the path information of the binary tree shared path, performing data value filling on the check transaction data to obtain target data; uploading the target data, a hash value corresponding to a root node of the binary tree shared path, a serial number identifier of the check transaction data, an institution identifier of the target financial institution and signature information of the target financial institution to a block chain for evidence storage to obtain a block chain certificate; and sending the block chain certificate to block chain node servers of other financial institutions. The technical problem of poor information security in the existing check transaction process is solved.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a blockchain-based method, apparatus, and electronic device for processing check transaction data. Background Technology

[0002] Electronic checks, as a digital form of traditional checks, aim to improve payment efficiency and security, reduce the use of physical checks, and avoid the inconvenience and risks of carrying and storing paper checks. However, with the widespread application of electronic checks in the financial sector, the issue of information security has become increasingly prominent, becoming a key obstacle restricting the further development and application of electronic check systems.

[0003] For example, traditional electronic check systems rely primarily on encrypted storage in centralized databases and protection within the bank's internal network during data processing and transmission. This model is vulnerable to cyberattacks, especially those targeting data integrity (such as tampering with check amounts or payee information) and confidentiality (such as stealing sensitive information about the drawee and payee). Once the central server is compromised, the security of check transaction data is severely threatened.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a blockchain-based check transaction data processing method, apparatus, and electronic device to at least solve the technical problem of poor information security in existing check transaction processes.

[0006] According to one aspect of the embodiments of this application, a blockchain-based check transaction data processing method is provided, comprising: receiving check transaction data uploaded by an application server through a blockchain node server of a target financial institution; generating a binary tree shared path based on the check transaction data, wherein the binary tree shared path is used to record blockchain scenario information when the blockchain node server of the target financial institution shares check transaction data with blockchain node servers of other financial institutions, wherein the other financial institutions are financial institutions other than the target financial institution in the blockchain network; filling the check transaction data with data values ​​according to the scenario identifier on the blockchain and the path information of the binary tree shared path to obtain target data; uploading the target data, the hash value corresponding to the root node of the binary tree shared path, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution to the blockchain for notarization to obtain a blockchain certificate; and sending the blockchain certificate to the blockchain node servers of other financial institutions, wherein the blockchain node servers of other financial institutions are used to verify the received check transaction data based on the blockchain certificate.

[0007] Optionally, before sending the blockchain credentials to the blockchain node servers of other financial institutions, the physical addresses of the blockchain node servers of other financial institutions and the requests initiated by the blockchain node servers of other financial institutions for obtaining check transaction data are obtained through the blockchain node servers of the target financial institution; Gaussian noise is added to the physical addresses and requests for obtaining data to generate a disturbance dataset; and the data in the disturbance dataset is modified by the target model over time.

[0008] Optionally, the process of determining the target model includes: obtaining the user dataset corresponding to the x-th physical address and the user dataset corresponding to the y-th physical address, wherein the x-th physical address and the y-th physical address are different physical addresses; splitting the user dataset corresponding to the x-th physical address into a first user set and a first interest set; splitting the user dataset corresponding to the y-th physical address into a second user set and a second interest set; integrating the first interest set and the second interest set into a target interest set, wherein the similarity between the product of the target interest set and the first user set and the user dataset corresponding to the x-th physical address is greater than a preset threshold, and the similarity between the product of the target interest set and the second user set and the user dataset corresponding to the y-th physical address is greater than a preset threshold; and determining the target model based on the target interest set.

[0009] Optionally, after sending the blockchain certificate to the blockchain node server of another financial institution, the shared information is obtained through the blockchain node server of the other financial institution based on the blockchain certificate. The shared information includes: the blockchain scenario identifier to be confirmed, the blockchain scenario data serial number, the institution identifier of the target financial institution, and the signature information of the target financial institution; determining the target binary tree shared path generated in the blockchain scenario corresponding to the blockchain scenario identifier; determining the target hash value corresponding to the root node of the target binary tree shared path based on the blockchain scenario data serial number to be confirmed; determining the public key information of the target financial institution recorded on the blockchain based on the institution identifier of the target financial institution; and verifying the check transaction data based on the target hash value and the public key information.

[0010] Optionally, the check transaction data is verified based on the target hash value and public key information, including: verifying the signature information of the target financial institution in the shared information based on the public key information; determining whether the data source of the shared information is a correct data source based on the verification result of the signature information; if the data source of the shared information is determined to be a correct data source, checking whether the target hash value is the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate; if the target hash value is found to be the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, determining that the check transaction data has passed verification; if the target hash value is found to be different from the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, determining that the check transaction data has failed verification.

[0011] Optionally, before receiving the check transaction data uploaded by the application server through the blockchain node server of the target financial institution, the application server obtains the user information provided by the user from the check transaction terminal; a registered account is generated based on the user information provided by the user; and a master key, user key, and public key corresponding to the registered account are generated.

[0012] Optionally, generating a master key, user key, and public key corresponding to the registered account includes: obtaining the generator and order of the bijective group, where the generator represents the set of elements that generate the entire bijective group, and the order represents the total number of elements in the bijective group; randomly selecting a first value, a second value, and a third value, where the first value, the second value, and the third value are different values; generating a master key based on the first value, the second value, and the generator; generating a user key based on the generator, the third value, and the first value; and generating a public key based on the generator, the order, the first value, and the second value.

[0013] Optionally, before sending the blockchain credentials to the blockchain node servers of other financial institutions, a peer-to-peer consensus operation is performed between the blockchain node servers of the target financial institution and the blockchain node servers of other financial institutions. The consensus operation is used to reach a consensus on the check transaction data in multiple stages. The results of the consensus operation are saved in the blockchain blocks.

[0014] According to another aspect of this application, a blockchain-based check transaction data processing device is also provided, comprising: a receiving unit for receiving check transaction data uploaded by an application server through a blockchain node server of a target financial institution; a first processing unit for generating a binary tree shared path based on the check transaction data through the blockchain node server of the target financial institution, wherein the binary tree shared path is used to record blockchain scenario information when the blockchain node server of the target financial institution shares check transaction data with blockchain node servers of other financial institutions, wherein the other financial institutions are financial institutions other than the target financial institution in the blockchain network; a data filling unit for filling the check transaction data with data values ​​according to the scenario identifier on the blockchain and the path information of the binary tree shared path to obtain target data; a second processing unit for uploading the target data, the hash value corresponding to the root node of the binary tree shared path, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution to the blockchain for notarization to obtain a blockchain certificate; and a sending unit for sending the blockchain certificate to the blockchain node servers of other financial institutions, wherein the blockchain node servers of other financial institutions are used to verify the received check transaction data based on the blockchain certificate.

[0015] According to another aspect of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is executed, the device in which the computer-readable storage medium is located performs the above-described blockchain-based check transaction data processing method.

[0016] According to another aspect of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the above-described blockchain-based check transaction data processing method.

[0017] According to another aspect of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described blockchain-based check transaction data processing method.

[0018] In this application, the target financial institution's blockchain node server first receives check transaction data uploaded by the application server. Then, a binary tree shared path is generated based on the check transaction data. This binary tree shared path records the blockchain scenario information when the target financial institution's blockchain node server shares check transaction data with other financial institutions' blockchain node servers. These other financial institutions are those outside the target financial institution within the blockchain network. Subsequently, based on the scenario identifier on the blockchain and the path information of the binary tree shared path, the check transaction data is populated with data values ​​to obtain the target data. The target data, the hash value corresponding to the root node of the binary tree shared path, the transaction serial number of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution are uploaded to the blockchain for notarization, resulting in a blockchain certificate. Finally, the blockchain certificate is sent to the blockchain node servers of the other financial institutions, which use the blockchain certificate to verify the received check transaction data.

[0019] As described above, the technical solution of this application combines blockchain technology with the processing of check transaction data, ensuring the authenticity and reliability of electronic check data, and guaranteeing the security, transparency, and immutability of check data information. Furthermore, it allows for binary tree modeling based on check transaction data, defining specific computational paths (i.e., the aforementioned shared binary tree path). In addition, on the blockchain, all transaction participants generate public-private key pairs representing their institutional identity. The private key is kept by the participant as proof of identity, while the public key is publicly disclosed on the blockchain to all chain members, serving as the key support for signing and verifying data authentication requests. This effectively solves the potential risk of enumerating and retrieving the original data due to the public disclosure of data on the blockchain, thereby resolving the technical problem of poor information security in existing check transaction processes. Attached Figure Description

[0020] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0021] Figure 1 This is a flowchart of a blockchain-based check transaction data processing method according to an embodiment of this application;

[0022] Figure 2 This is a schematic diagram of an optional check data processing system according to an embodiment of this application;

[0023] Figure 3 This is a schematic diagram of the structure of an optional blockchain node server according to an embodiment of this application;

[0024] Figure 4 This is a schematic diagram of an optional binary tree shared path according to an embodiment of this application;

[0025] Figure 5 This is a schematic diagram of an optional check customer terminal according to an embodiment of this application;

[0026] Figure 6 This is a schematic diagram of an optional application server according to an embodiment of this application;

[0027] Figure 7 This is a flowchart of an optional check data processing method according to an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of a check transaction data processing device according to this application. Detailed Implementation

[0029] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0030] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0031] It should also be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation entry points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding operation entry points for them to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0032] According to an embodiment of this application, an embodiment of a blockchain-based check transaction data processing method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0033] Figure 1 This is a flowchart of a blockchain-based check transaction data processing method according to an embodiment of this application, such as... Figure 1 As shown, the method includes the following steps:

[0034] Step S101: Receive check transaction data uploaded by the application server through the blockchain node server of the target financial institution.

[0035] In one optional embodiment, a check data processing system can serve as the execution entity for the blockchain-based check transaction data processing method of this application. This system can be a software system or an embedded system combining software and hardware. Furthermore, the execution entity for the check transaction data processing method in this application can also be other forms of entity, such as devices, equipment, etc. Those skilled in the art will understand that this application does not specifically limit the specific form of the execution entity.

[0036] Optionally, Figure 2 This is a schematic diagram of an optional check data processing system according to an embodiment of this application, such as... Figure 2 As shown, the check data processing system includes: check customer terminals, and application servers for various banks (e.g., ...). Figure 2 The application servers of Bank A and Bank C in the middle), and the blockchain node servers of each bank (e.g. Figure 2The blockchain nodes of Bank A, Bank B, Bank C, and Bank D, as well as the consortium blockchain network, are among them.

[0037] like Figure 2 As shown, the check customer terminal connects to the application server of its account opening bank via a wireless network; the bank's application server connects to the bank's blockchain node server via the network; and the blockchain node servers connect to each other via the network to form the entire blockchain network.

[0038] It should be noted that the target financial institution can be Figure 2 The target financial institution's blockchain node server can receive check transaction data from the connected application server, which is generated by the check client terminal and uploaded to the application server.

[0039] Step S102: Generate a binary tree shared path based on the check transaction data.

[0040] The binary tree shared path is used to record blockchain scenario information when the blockchain node server of the target financial institution shares check transaction data with the blockchain node servers of other financial institutions. The other financial institutions are financial institutions in the blockchain network other than the target financial institution.

[0041] Step S103: Based on the scene identifier on the blockchain and the path information of the binary tree shared path, fill the check transaction data with data values ​​to obtain the target data.

[0042] Step S104: Upload the target data, the hash value corresponding to the root node of the binary tree shared path, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution to the blockchain for notarization, and obtain a blockchain certificate.

[0043] Optionally, the blockchain node server of the target financial institution can generate a binary tree shared path based on the check transaction data; wherein, the binary tree data generation module is also used to fill the check transaction data with data values ​​according to the scene identifier on the blockchain and the path information of the binary tree shared path to obtain the target data.

[0044] The blockchain node server of the target financial institution can also calculate the hash value corresponding to the root node of the shared path of the binary tree, the serial number identifier of the check transaction data, the institution identifier of the data provider of the check transaction data (such as the target financial institution), and the signature information, and upload them to the blockchain for evidence storage.

[0045] In one optional embodiment, the blockchain node server can handle transaction requests related to data flow, including the identity identifiers and public key information of the data provider and data requesting institutions, as well as the ability to store and retrieve evidence by performing binary tree root hashing on transaction business scenario process data. It can be deployed in a distributed manner within participating financial institutions such as banks, UnionPay, and SWIF in the alliance. It is a consensus transaction that requires consensus from all consensus nodes on the blockchain. During the consensus process, each blockchain node must receive consistent confirmation messages from 2f+1 other blockchain nodes before consensus can be completed. The data processed according to the logic in the contract generates new block data and triggers the relevant business processes after the contract is executed. Query transactions directly obtain the corresponding world state data from the corresponding blockchain node without needing to go through consensus.

[0046] Optionally, Figure 3 This is a schematic diagram of the structure of an optional blockchain node server according to an embodiment of this application, such as... Figure 3 As shown, the blockchain node server includes: a transaction consensus module 31, a transaction execution module 32, a binary tree data generation module 33, a data authentication module 34, an on-chain interaction module 35, and an identity anonymity module 36.

[0047] Optionally, the transaction consensus module 31 is responsible for peer-to-peer consensus information interaction with all blockchain node servers in the blockchain and completing the core module of transaction consensus. It achieves consensus on the transaction result, specifically a three-stage consensus process of Byzantine consensus algorithm. The first stage is pre-prepare consensus, the second stage is prepare consensus, and the third stage is commit consensus. The three stages are executed sequentially. After the current stage receives at least 2f+1 consistent confirmation messages from other transaction consensus nodes, the consensus of the current stage is completed and the next stage is entered. After the consensus of all three stages is completed, it means that the requested transaction is legal and can enter the transaction execution module 32 for processing.

[0048] Optionally, the transaction execution module 32 is responsible for executing smart contract requests and persisting the ledger. It saves the transaction success information, transaction result information, and SeqNo (i.e., block consensus result) of the block consensus completed by the transaction consensus module 31 into the block, records the transaction log and sends the block execution success event, performs strong consistency checks on the blockchain nodes (block height, predecessor, current hash), and finally updates the world state information.

[0049] Optionally, the binary tree data generation module 33 is responsible for processing the shared data between participating data providers and requesting organizations, including generating verifiable shared data as a data provider. This module generates a binary tree sharing path for the scenario data to be shared, and uploads it to the blockchain. It also generates and uploads the root hash of the shared data binary tree (i.e., the hash value corresponding to the root node of the binary tree, which can also be understood as the hash value corresponding to the root node of the binary tree sharing path). Furthermore, it generates shared data information that can be verified through the binary tree for users applying for data sharing. Through this module's processing of shared data on the blockchain, the potential risk of enumerating and retrieving the original data due to public disclosure of data on the blockchain can be effectively resolved, ensuring on-chain data privacy and security. The specific steps are as follows:

[0050] like Figure 4 As shown, the newly added data sharing business scenario type and the consortium institutions on the blockchain network agree on the data format, generate a binary tree sharing path, and store it on the blockchain. The shared fields are split into Data1, Data2, Data3, and Data4, and each data point is used as a leaf to calculate layer by layer until the HashRoot (the hash value corresponding to the root node of the binary tree sharing path). The information stored on the blockchain includes the scenario ID and the binary tree sharing path information. Specifically, calculating Data1 to the HashRoot requires calculating Hash1 and Hash12 in sequence; calculating Data2 to the HashRoot requires calculating Hash2 and Hash12 in sequence; calculating Data3 to the HashRoot requires calculating Hash3 and Hash34 in sequence; and calculating Data4 to the HashRoot requires calculating Hash4 and Hash34 in sequence.

[0051] Optionally, for data sharing scenarios with a designed binary tree shared path, the data provider on the blockchain network can directly upload the HashRoot of the shared data to the chain for notarization. That is, first obtain the binary tree shared path information of the scenario from the chain according to the scenario ID, replace the specific field information of the leaf node with the specific shared data value, obtain the HashRoot, and upload the HashRoot, the signature information of the HashRoot by the data provider using its own private key information, and the transaction information of the data together to the chain for notarization.

[0052] Step S105: Send the blockchain certificate to the blockchain node server of other financial institutions.

[0053] In step S105, the blockchain node servers of other financial institutions are used to verify the received check transaction data based on the blockchain credentials.

[0054] Optionally, when a blockchain node server of another financial institution needs to request to read check transaction data from the blockchain node server of the target financial institution in the form of its own data, a binary tree shared path information carrying the data and data verification is generated based on the fields requested by the blockchain node server of the other financial institution. For example, if the information requested by the blockchain node server of the other financial institution is Data1, the corresponding calculation path is Data1, Hash2, Hash34. That is, the shared information provided to the blockchain node server of the other financial institution includes the scenario ID, scenario data serial number, data information (Data1 and Hash2, Hash34), provider identity ID (e.g., the institutional identifier of the target financial institution), and provider signature information.

[0055] Based on steps S101 to S105, in this application, the target financial institution's blockchain node server first receives check transaction data uploaded by the application server. Then, a binary tree shared path is generated based on the check transaction data. This binary tree shared path records the blockchain scenario information when the target financial institution's blockchain node server shares check transaction data with other financial institutions' blockchain node servers. These other financial institutions are those outside the target financial institution within the blockchain network. Subsequently, the check transaction data is populated with data values ​​based on the scenario identifier on the blockchain and the path information of the binary tree shared path to obtain target data. The target data, the hash value corresponding to the root node of the binary tree shared path, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution are uploaded to the blockchain for notarization, resulting in a blockchain certificate. Finally, the blockchain certificate is sent to the blockchain node servers of other financial institutions, which verify the received check transaction data based on the blockchain certificate.

[0056] As described above, the technical solution of this application combines blockchain technology with the processing of check transaction data, ensuring the authenticity and reliability of electronic check data, and guaranteeing the security, transparency, and immutability of check data information. Furthermore, it allows for binary tree modeling based on check transaction data, defining specific computational paths (i.e., the aforementioned shared binary tree path). In addition, on the blockchain, all transaction participants generate public-private key pairs representing their institutional identity. The private key is kept by the participant as proof of identity, while the public key is publicly disclosed on the blockchain to all chain members, serving as the key support for signing and verifying data authentication requests. This effectively solves the potential risk of enumerating and retrieving the original data due to the public disclosure of data on the blockchain, thereby resolving the technical problem of poor information security in existing check transaction processes.

[0057] In one optional embodiment, after sending the blockchain credential to the blockchain node server of another financial institution, the blockchain node server of the other financial institution obtains shared information based on the blockchain credential. This shared information includes: a blockchain scenario identifier to be confirmed, a blockchain scenario data serial number, the institution identifier of the target financial institution, and the signature information of the target financial institution; determines the target binary tree shared path generated in the blockchain scenario corresponding to the blockchain scenario identifier; determines the target hash value corresponding to the root node of the target binary tree shared path based on the blockchain scenario data serial number to be confirmed; determines the public key information of the target financial institution recorded on the blockchain based on the institution identifier of the target financial institution; and verifies the check transaction data based on the target hash value and the public key information.

[0058] Optionally, each blockchain node server further includes: a data authentication module 34, used to obtain shared information provided by any application server, wherein the shared information includes: the blockchain scenario identifier to be confirmed, the blockchain scenario data serial number, the check transaction data and hash value corresponding to the user, the institution identifier of the data provider, and the signature information of the data provider; the data authentication module is also used to obtain the target binary tree shared path corresponding to the scenario based on the blockchain scenario identifier, obtain the target hash value corresponding to the root node of the target binary tree shared path based on the scenario data serial number, and obtain the public key information of the data provider recorded on the blockchain based on the institution identifier of the data provider.

[0059] In one optional embodiment, the check transaction data is verified based on the target hash value and public key information, including: verifying the signature information of the target financial institution in the shared information based on the public key information; determining whether the data source of the shared information is a correct data source based on the verification result of the signature information; if the data source of the shared information is determined to be a correct data source, detecting whether the target hash value is the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate; if the target hash value is detected to be the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, determining that the check transaction data has passed verification; if the target hash value is detected to be different from the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, determining that the check transaction data has failed verification.

[0060] Optionally, the data authentication module is also used to perform the following steps:

[0061] The signature information of the data provider in the shared information is verified based on the public key information of the data provider, and the data source of the shared information is determined to be the correct data source based on the verification result of the signature information.

[0062] If the data source of the shared information is determined to be the correct data source, check whether the target hash value is the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate;

[0063] If the target hash value is found to be the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain credential, the check transaction data is determined to be verified.

[0064] If the target hash value is found to be different from the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain credential, it is determined that the check transaction data has failed verification.

[0065] It should be noted that the data authentication module 34 refers to the process by which the data requester obtains the shared binary tree path and the root of the shared data binary tree (HashRoot) from the blockchain to verify the authenticity of the data when obtaining shared data provided by the user.

[0066] First, obtain the shared information provided by the user: Scene ID (corresponding to the blockchain scene identifier mentioned above), Scene data serial number, and data information (e.g., Figure 4 The data provider includes Data1, Hash2, Hash34, the data provider identifier ID, and the data provider's signature information. Then, based on the scenario ID, the target binary tree shared path corresponding to the scenario is obtained; based on the scenario data serial number, the corresponding data binary tree root HashRoot is obtained; and based on the data provider identifier ID, the identity public key information of the on-chain provider is obtained.

[0067] Secondly, the public key information of the data provider is used to verify the signature information of the data provider in the data information. If the verification is successful, it means that the data source is genuine.

[0068] Finally, using the shared binary tree path and data information corresponding to the scenario, calculate HashRoot = Hash(Hash(Hash(Data1), Hash2), Hash34) = Hash(Hash(Hash1, Hash2), Hash34) = Hash(Hash12, Hash34) to obtain the target hash value. Then, compare it with the HashRoot value of the binary tree root obtained on the chain (the hash value corresponding to the root node of the shared binary tree path). If the comparison is consistent, it means that the data information is consistent with the data provided by the source and is real.

[0069] Optionally, the on-chain interaction module 45 of each blockchain node server is responsible for completing the on-chain interaction. As a data provider, the institution will store the scene ID and binary tree calculation path corresponding to the data scene on the chain, and store the scene data flow ID and data binary tree root hash of the shared data on the chain. As a data requester, the institution will retrieve the information required for data authentication from the chain. The storage of evidence requires the institution's identity signature information to be synchronized on the chain, and the retrieval of evidence requires the use of privacy protection technology to perform on-chain identity and permission verification while protecting the real identity.

[0070] In one optional embodiment, before sending the blockchain credentials to the blockchain node servers of other financial institutions, the physical addresses of the blockchain node servers of other financial institutions and the requests initiated by the blockchain node servers of other financial institutions for obtaining check transaction data are obtained through the blockchain node servers of the target financial institution; Gaussian noise is added to the physical addresses and requests for obtaining data to generate a disturbance dataset; and the data in the disturbance dataset is modified by the target model over time.

[0071] Optionally, the anonymity module of each blockchain node server is responsible for obtaining and verifying the information stored on the blockchain by the data provider through the on-chain interaction module when the data requesting institution verifies the on-chain data. It should be noted that the on-chain verification of the data requesting party's alliance identity is required. However, the data requesting party does not want to expose its identity information to the data provider, which could lead to business losses. The industry often uses common privacy protection technologies such as ring signatures, but ring signature technology has some drawbacks: for example, existing ring signature schemes usually require the signature length to be positively correlated with the number of ring members. To control transaction costs, these schemes often need to limit the signature length, thus limiting the number of ring members. This may result in insufficient anonymity. Attackers can analyze multiple transactions of a virtual identity through transaction graphs and infer the real identity of this virtual identity based on the correlation between transactions. There are also verifiability issues; in some practical applications, the verifier needs to confirm the identity of the real signer.

[0072] Existing ring signature schemes may struggle to meet this requirement. For example, certificateless verifiable ring signature schemes and verifiable proxy ring signature schemes may have security vulnerabilities, such as any member in the ring being able to forge other members to generate ring signatures, while the true identity verification algorithm points to the latter as the signer's real identity. Scalability is also an issue; existing ring signature schemes may have limitations in scalability, such as difficulty adapting to large-scale blockchain networks.

[0073] This application employs a novel information protection method. By protecting the physical address of the data requester, Gaussian noise is added to the data packets containing the object address and request data of the requester to generate an interference dataset. At the same time, a training model is established and continuously trained and changed to prevent attackers from analyzing multiple transaction information of a virtual identity through transaction graphs and other means. Based on the correlation between transactions, attackers can infer the real identity of this virtual identity in reality, thus proving that their authority is within the blockchain consortium while not disclosing which institution on the chain they belong to.

[0074] Therefore, the identity anonymization module includes: a model determination submodule, used to perform the following steps:

[0075] Obtain the user dataset corresponding to the x-th physical address and the user dataset corresponding to the y-th physical address, where the x-th physical address and the y-th physical address are different physical addresses;

[0076] Split the user dataset corresponding to the xth physical address into a first user set and a first interest set;

[0077] Split the user dataset corresponding to the y-th physical address into a second user set and a second interest set;

[0078] The first interest set and the second interest set are integrated into a target interest set, wherein the product of the target interest set and the first user set has a similarity greater than a preset threshold with the user dataset corresponding to the x-th physical address, and the product of the target interest set and the second user set has a similarity greater than a preset threshold with the user dataset corresponding to the y-th physical address; the target model is determined based on the target interest set.

[0079] The specific steps are as follows:

[0080] 1. The data requesting organization synchronizes the public key information corresponding to the identity IDs of all participants on the current blockchain from the blockchain based on the update push notifications from the on-chain participants;

[0081] 2. When the data requester invokes the on-chain interaction module to obtain on-chain evidence information, it uses its own identity ID's private key and the public key corresponding to the identity ID of other participants on the blockchain to sign.

[0082] 3. Initialize the signed message data. To protect user privacy, the data owner will not disclose their identity information to other client nodes. Therefore, if the same user appears at different physical addresses, the system considers them to be different users. Let physical addresses site1 (corresponding to the x-th physical address mentioned above) and site2 (corresponding to the y-th physical address mentioned above) respectively store their respective user datasets M. (1) and M (2)The user set of site1 is U (1) (corresponding to the first user mentioned above), the interest set is V. (1) (corresponding to the first interest mentioned above), the user set of site2 is U. (2) (Corresponding to the second user set mentioned above), the interest set is V. (2) (Corresponding to the second interest set mentioned above), the user dataset satisfies the following coupling formula:

[0083] M (1) ≈U (1) V (1)

[0084] M (2) ≈U (2) V (2)

[0085] Let V be the full set of interests (corresponding to the target set of interests mentioned above), satisfying:

[0086]

[0087] If the interest sets of site1 and site2 are both set to V, then the following collaborative coupling is achieved:

[0088] M (1) ≈U (1) V

[0089] M (2) ≈U (2) V

[0090] V is used as a public parameter and is shared across the entire network through the blockchain consensus mechanism.

[0091] 4. Generate a probability model, specifying... For the conditionally distributed observation dataset, in and V∈R D×J The prior probability distribution model is constructed above, where R is the set of real numbers, and I1 and D are matrices U. (1) Let D and J be the rows and columns of matrix V, and let j be the index of the interest set and i1 be the index of the user set.

[0092]

[0093]

[0094] In formulas (1) to (3) above, ρo represents the Poisson distribution function. Let represent the gamma distribution function, and α and β represent the shape parameter and scale parameter, respectively; θ V =(α V ,β V) represents the training constant.

[0095] And so on, based on this, we can define For the conditionally distributed observation dataset, in and V∈R D×J The prior probability distribution model is constructed above. Here, I² and D are matrices U. (2) The rows and columns of matrix V are D and J, respectively.

[0096] Finally, the posterior distribution p is defined based on the datasets from site1 and site2. (1) and p (2) It is proportional to the prior distribution, as follows:

[0097]

[0098] in,

[0099] 5. Perform differential privacy computation. For any two datasets M and Z, their similarity can be calculated using Hamming distance. Given a randomized algorithm A, the differential privacy formula (∈,δ)-DP satisfies:

[0100] P(A(M)∈S)≤e ∈ P(A(Z)∈S)+δ (6)

[0101] Here, S represents the range of the random algorithm A. δ is selected from the binomial distribution function N(0, 2k). t ), k t To verify the step size.

[0102] Select sample dataset B from M. (n,t) A dataset of length B is generated by adding Gaussian noise to generate an interference dataset Z. (n,t) ,Right now:

[0103] Z (n,t) ≈U (n,t) V+δ (t) (7)

[0104] 6. Update the user dataset. The user dataset with physical address n and iteration number t is U. (n,t) Its update rules are as follows:

[0105]

[0106] in:

[0107]

[0108] As can be seen from the above, a binary tree model is constructed by extracting the corresponding set of shared data fields according to the business scenario, and the calculation path for verifying specific fields is agreed upon. All participants generate public and private key pairs that can represent their organizational identity. The private key is kept by the participants as proof of their identity, and the public key is publicly disclosed to the chain members on the chain. It serves as the key support for signing and verifying data authentication requests. This effectively solves the hidden danger of enumerating and reversing the original data due to the public disclosure of data on the chain, and ensures the security of on-chain data.

[0109] Furthermore, the anonymity module employs a novel information protection method. By protecting the physical address of the data requester, Gaussian noise is added to the data packets containing the requester's object address and request data to generate an interference dataset. Simultaneously, a training model is established and continuously trained and modified to prevent attackers from analyzing multiple transactions of a virtual identity through transaction graphs and other means. Based on the correlation between transactions, attackers could infer the virtual identity's real-world identity, thus proving that their authority is within the blockchain consortium while concealing their affiliation within the chain, protecting the privacy of the requesting client. This also avoids the limitations of traditional privacy protection methods (such as ring signatures), which require signature length restrictions, thus limiting the number of ring members and compromising anonymity. Attackers can analyze multiple transactions of a virtual identity and infer its real-world identity based on the correlation between transactions, ensuring the privacy and security of the winner's personal information.

[0110] In one optional embodiment, before receiving the check transaction data uploaded by the application server through the blockchain node server of the target financial institution, the application server obtains the user information provided by the user from the check transaction terminal; a registered account is generated based on the user information provided by the user; and a master key, user key, and public key corresponding to the registered account are generated.

[0111] Optionally, the check customer terminal is responsible for providing check customers with services such as downloading and registering electronic check software modules, checking issuance transactions, checking progress information inquiries, and fund usage information inquiries, and performs group signature, encryption, and decryption processing on transaction request data. Preferably, this software can be integrated as a functional module into the bank's mobile banking APP.

[0112] Figure 5 This is a schematic diagram of an optional check customer terminal according to an embodiment of this application, such as... Figure 5 As shown, the check customer terminal can be a customer's smartphone, tablet, laptop, or other terminal device. The check customer terminal may include: a user registration module 51, a key generation module 52, a check issuance module 53, and a check inquiry module 54.

[0113] Among them, the user registration module 51 is responsible for providing the interface and interface for customers to register on the system and obtain check user identity. During registration, relevant personal identity information needs to be submitted. After successful registration, check-related keys and personal digital certificates are downloaded to ensure data security during check opening and cashing transactions.

[0114] Optionally, after a user successfully registers an account, the key generation module 22 generates a master key M for the client. k User key S k And public key PK.

[0115] It's important to note that key information typically includes a public and private key pair, while digital certificates are used to verify the legitimacy of user identities, ensuring that only legitimate users can perform related operations. The user registration module, by generating registered accounts, user-bound key information, and personal digital certificates, not only verifies and manages user identities but also provides security for subsequent lottery transactions. The use of digital certificates and keys ensures that user information and transaction data are encrypted and protected even in public network environments, effectively preventing data leaks and unauthorized access, and significantly enhancing system security. After successful user registration, the key generation module generates a master key, user key, and public key corresponding to the user's registered account. The master key is typically used to manage the user's key system and is the foundation of the entire key system; the user key is directly associated with specific user operations and is used to encrypt and decrypt user data; and the public key is used to verify user signatures and can be publicly disclosed in the blockchain network for other nodes to authenticate the data. Through the key system generated by the key generation module, the system ensures the data security of users during lottery transactions. The user key is used to encrypt transaction data submitted by the user, ensuring that this data cannot be stolen or tampered with during transmission; while the public key is used for data authentication within the blockchain network, ensuring the authenticity and trustworthiness of the data source. The existence of the master key further enhances the security of key management; even if some keys are leaked, it is difficult to affect the overall security of the user account, thus providing users with multi-layered security protection.

[0116] In an optional embodiment, the key generation module 52 may perform the following steps: obtaining the generator and order of the bijective group, wherein the generator represents the set of elements that generate the entire bijective group, and the order represents the total number of elements in the bijective group; randomly selecting a first value, a second value, and a third value, wherein the first value, the second value, and the third value are different values; generating a master key based on the first value, the second value, and the generator; generating a user key based on the generator, the third value, and the first value; and generating a public key based on the generator, the order, the first value, and the second value.

[0117] Optionally, the key generation module 52 generates a master key M for the user.k User key S k And the public key PK, the specific generation method is as follows:

[0118] First, after a client successfully registers, the system submits a request to initialize security parameters. Then, upon receiving the request, the client calls the key initialization module `setup` to generate the master key; subsequently, it calls the key generation module to generate the key `S`. k .

[0119] The specific steps are as follows:

[0120] 1. Initialization (Setup): The setup module selects a bijective group G0 with generator g and prime order p. In the array Z... p Two random numbers α, β ∈ Z are randomly selected. p As an index, the public key is represented as a tuple: Where 'e' refers to a preset coefficient, DID H ∈DID represents the DID of the digital file owner (Host). α corresponds to the first value mentioned above, and β corresponds to the second value mentioned above. M k =(β,g α ) represents the master key.

[0121] 2. Generate key: Supplement the input parameters, represented as keyGen(M) k ,S), where M k Let S be the master key and S be the set of attributes. The value produced by this function is the key. Where, r∈Z p For each attribute j∈S, r is a random number (corresponding to the third value mentioned above). j ∈Z p H is a random number, and H is a preset coefficient corresponding to attribute j.

[0122] Optionally, the key generation module 52 can also call the blockchain smart contract algorithm to initialize security parameters; execute the notarization processing smart contract to notarize the user's public key and master key; and notarize the digital identity DID and master key M. k The user's public key PK is stored as evidence, and the Encry encryption function is executed to encrypt the symmetric key, generating the symmetric key pk. b ciphertext Finally, the key generation module 22 sends the security parameters back to the client, stores the symmetric private key locally, and returns a message indicating successful initialization of the security parameters.

[0123] It should be noted that this technique ensures fundamental security in key generation by using a bijective group and its generator g and order p. The properties and structure of the bijective group provide a robust mathematical framework, guaranteeing the randomness and unpredictability of key generation. The order p, representing the total number of elements in the bijective group, significantly increases the key space when a large prime number is chosen, thereby enhancing key security and making key cracking extremely difficult. The key generation module generates the master key M, user key, and public key by randomly selecting a first value α, a second value β, and a third value r, combined with the generator g and order p. This generation method ensures the uniqueness and security of each key. The master key M, generated from the first value α, the second value β, and the generator g, is used for system-level key management and user key generation. The user key, generated from the generator g, the third value r, and the first value α, is used for encrypting and decrypting user data. The public key, generated from the generator g, order p, the first value α, and the second value β, is used for data encryption and signature verification, and can be securely published in the blockchain network for verifying signatures generated by the private key.

[0124] Furthermore, the random selection of the first value α, the second value β, and the third value r is a crucial step in key generation, ensuring the unpredictability of the key. In cryptography, randomness is fundamental to key generation, preventing the key from being pre-computed or guessed, thus ensuring its security and validity. Even if the key is leaked, randomness makes it difficult to reuse or reverse engineer it.

[0125] Optionally, the check issuance module 53 provides an interface for customers to submit check issuance transaction applications on the system. Upon submission, it will cooperate with other modules to collect and encrypt customer check transaction information data. This information includes, but is not limited to: check type, drawer's name, drawer's bank name and code, drawer's account number, date of issue, amount and currency, payee's name, payee's bank name and account number, check validity period, specified purpose and direction of use, etc. When a check customer registers a check transaction application with the bank for the first time, the drawer's name, drawer's bank name and code, and drawer's account number are automatically generated from the bank's application server and stored on both the bank's application server and the check customer's terminal.

[0126] The check inquiry module 54 is responsible for providing users with an inquiry interface and API to check the cashing progress of their checks and the use of funds in their check account.

[0127] In one optional embodiment, the financial institution's application server is responsible for authenticating check customers, checking the legality of check transaction data, processing check transactions according to the check objects in the data and registering them in the transaction register, and processing check query transaction data.

[0128] Figure 6 This is a schematic diagram of an optional application server according to an embodiment of this application, such as... Figure 6 As shown, the application server includes: identity verification module 61, check issuance processing module 62, check query processing module 63, check verification module 64, and accounting processing module 65.

[0129] Optionally, the identity verification module 61 is responsible for authenticating the check customer's identity, including checking account number and password, and biometric verification. The check issuance processing module 62 is responsible for checking the legality of the check transaction data submitted by the check customer, generating electronic check data according to the check elements in the transaction data, and registering it in the transaction register. The check inquiry processing module 63 is responsible for inquiring about the check payment, deposit status, and check fund account status based on the check transaction submitted by the check customer. The check verification module 64 is responsible for verifying and checking the check confirmation data sent by the payee's bank during the payment process, using the public key provided by the other bank to check whether the confirmation data of the payee's bank is correct and complete. The accounting processing module 65 is responsible for freezing the funds in the newly opened check account according to the check amount during the check issuance stage. When the check is paid, after the check verification module passes the verification, the frozen funds are transferred to the payee's bank account specified in the check, and the transaction register is recorded.

[0130] In one alternative embodiment, Figure 7 This is a flowchart of an optional check data processing method according to an embodiment of this application. A charity organization has opened a dedicated charity account at Bank C. User Zhang San is a customer of Bank A. Zhang San donates a sum of money to the dedicated charity account in the form of an electronic check. He does not want his real identity to be known by the charity organization or the public, therefore he chooses to donate anonymously. The relevant data processing method is as follows:

[0131] Step S701: Check customer Zhang San downloads the check transaction software on his mobile phone. Preferably, the check transaction software can be integrated as a functional module into the bank's mobile banking software. The user registration module registers the customer, and after successful registration, downloads the relevant keys and personal digital certificates to ensure data security during transactions. The key generation module generates a master key M for the customer. k and user key S k .

[0132] In step S702, the check customer submits a check opening transaction application on the system through the check opening module interface on the customer terminal, and will use the master key M when submitting the application. kThe customer's check information data is encrypted. Customer transaction information data includes, but is not limited to: check type, drawer's name, drawer's bank name and code, drawer's account number, check date, check amount and currency, payee's name, payee's bank name and account number, check validity period, check's intended purpose and direction of use, etc. The check issuance module sends the transaction-related data to Bank A's application server.

[0133] In step S703, the identity verification module of Bank A's application server authenticates the identity of the check customer, decrypts the transaction data using the user's public key, and checks the legality of the check transaction data submitted by the check customer. After the verification is passed, the funds corresponding to the customer's account are frozen according to the check amount and registered in the transaction register. The check transaction data is then synchronized with Bank A's blockchain node server.

[0134] In step S704, Bank A's blockchain node server initializes, including initializing the master private key and generating a public-private key pair representing the current institution's identity based on the master private key. The master private key and identity private key are stored by Bank A's blockchain node server, while the identity public key is synchronized to all blockchain node servers on the blockchain network. After encrypting the transaction data using Bank A's private key, the transaction execution module on Bank A's blockchain node server completes the smart contract request execution and ledger persistence. It saves the successful transaction information, transaction result information, and block consensus SeqNo completed by the transaction consensus module into the block, records the transaction log, sends a block execution success event, performs strong consistency checks on the blockchain nodes (block height, predecessor, current hash), and finally updates the world state information.

[0135] In step S705, the binary tree data generation module of Bank A's blockchain node server models the shared funding data using a binary tree sharing path. It fills the shareable data with specific data values ​​based on the on-chain scenario ID and binary tree path information, and uploads the calculated binary tree root hash, the data's serial number ID, the provider's institution identity ID, and the provider's institution identity ID's signature information to the blockchain for evidence storage.

[0136] In step S706, the anonymization device of Bank A's blockchain node server protects the privacy of transaction request data. This is achieved by protecting the physical address of the data requester, adding Gaussian noise to the data packets containing the requester's object address and request data to generate an interference dataset. Simultaneously, a training model is established, continuously training and changing the interference dataset to prevent attackers from analyzing multiple transactions of a virtual identity through transaction graphs and other means, and from inferring the real identity of this virtual identity based on the correlation between transactions, thus preventing the leakage of customer identity privacy data. Bank A's blockchain node server then synchronizes data with the blockchain node servers of other banks.

[0137] In step S707, after receiving the transaction data packet, the blockchain node server of Bank C obtains the binary tree path and the shared data binary tree root HashRoot from the chain to verify the authenticity and integrity of the data.

[0138] In step S707, firstly, the shared information provided by the user is obtained: scenario ID, scenario data serial number, data information (Data1, Hash2, Hash34), provider organization identifier ID, and provider signature information. Then, the data binary tree calculation path corresponding to the scenario is obtained based on the scenario ID, the corresponding data binary tree root HashRoot is obtained based on the scenario data serial number, and the identity public key information of the on-chain provider organization is obtained based on the provider organization identifier ID.

[0139] Secondly, the provider's signature information in the datagram is verified using the provider's public key information. If the verification is successful, it means that the data source is genuine.

[0140] Finally, using the binary tree calculation path and data information corresponding to the scenario, calculate HashRoot = Hash(Hash(Hash(Data1), Hash2), Hash34) = Hash(Hash(Hash1, Hash2), Hash34) = Hash(Hash12, Hash34), and check it against the HashRoot value of the binary tree root obtained from the chain. If the check is consistent, it means that the data information is consistent with the data provided by the source and is real.

[0141] After successful verification, the transaction data packet is sent to Bank C's application server.

[0142] In step S708, Bank C's application server uses Bank A's public key to decrypt the check data and checks for any anomalies in the customer's account status and information. After confirming everything is correct, the transaction confirmation data is encrypted using Bank C's key and returned to Bank A's application server via the blockchain node server and blockchain network. Preferably, Bank C only knows that the transaction is genuine and valid based on the transaction data, but cannot know the check user's detailed information, thus protecting the check user's personal privacy.

[0143] Step S709: After Bank A's application server decrypts the data using Bank C's public key, based on Bank C's confirmation, the accounting module unfreezes the funds frozen on the check, initiates a transfer transaction to the payee's bank account at Bank C, and registers it in the transaction register. The transaction is complete.

[0144] In an optional embodiment, a blockchain-based check transaction data processing device is also provided, wherein, Figure 8 This is a schematic diagram of a check transaction data processing device according to this application, such as... Figure 8 As shown, the device includes: a receiving unit 801, a first processing unit 802, a data filling unit 803, a second processing unit 804, and a sending unit 805.

[0145] Optionally, the receiving unit 801 is used to receive check transaction data uploaded by the application server through the blockchain node server of the target financial institution; the first processing unit 802 is used to generate a binary tree shared path based on the check transaction data through the blockchain node server of the target financial institution, wherein the binary tree shared path is used to record the blockchain scenario information when the blockchain node server of the target financial institution shares check transaction data with the blockchain node servers of other financial institutions, wherein the other financial institutions are financial institutions other than the target financial institution in the blockchain network; the data filling unit 803 is used to fill the check transaction data with data values ​​according to the scenario identifier on the blockchain and the path information of the binary tree shared path to obtain target data; the second processing unit 804 is used to upload the target data, the hash value corresponding to the root node of the binary tree shared path, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution to the blockchain for notarization to obtain a blockchain certificate; the sending unit 805 is used to send the blockchain certificate to the blockchain node server of other financial institutions, wherein the blockchain node server of other financial institutions is used to verify the received check transaction data based on the blockchain certificate.

[0146] Optionally, the blockchain-based check transaction data processing device further includes: an acquisition unit, used to acquire the physical address of the blockchain node server of other financial institutions, and the acquisition request for check transaction data initiated by the blockchain node server of other financial institutions through the blockchain node server of the target financial institution; a noise addition unit, used to add Gaussian noise to the physical address and acquisition request to generate an interference dataset; and a data modification unit, used to modify the data in the interference dataset by changing the target model over time.

[0147] Optionally, the blockchain-based check transaction data processing device further includes: a first acquisition unit, configured to acquire user datasets corresponding to the x-th physical address and the y-th physical address, wherein the x-th physical address and the y-th physical address are different physical addresses; a first splitting unit, configured to split the user dataset corresponding to the x-th physical address into a first user set and a first interest set; a second splitting unit, configured to split the user dataset corresponding to the y-th physical address into a second user set and a second interest set; an integration unit, configured to integrate the first interest set and the second interest set into a target interest set, wherein the product of the target interest set and the first user set has a similarity greater than a preset threshold with the user dataset corresponding to the x-th physical address, and the product of the target interest set and the second user set has a similarity greater than a preset threshold with the user dataset corresponding to the y-th physical address; and a first determining unit, configured to determine a target model based on the target interest set.

[0148] Optionally, the blockchain-based check transaction data processing device further includes: a second acquisition unit, used to acquire shared information based on blockchain credentials through the blockchain node server of other financial institutions, wherein the shared information includes: a blockchain scenario identifier to be confirmed, a blockchain scenario data serial number, an institution identifier of the target financial institution, and the signature information of the target financial institution; a second determination unit, used to determine the target binary tree shared path generated in the blockchain scenario corresponding to the blockchain scenario identifier; a third determination unit, used to determine the target hash value corresponding to the root node of the target binary tree shared path based on the blockchain scenario data serial number to be confirmed; a fourth determination unit, used to determine the public key information of the target financial institution recorded on the blockchain based on the institution identifier of the target financial institution; and a verification unit, used to verify the check transaction data based on the target hash value and the public key information.

[0149] Optionally, the verification unit includes: a first verification subunit, used to verify the signature information of the target financial institution in the shared information based on the public key information; a judgment subunit, used to determine whether the data source of the shared information is a correct data source based on the verification result of the signature information; a detection subunit, used to detect whether the target hash value is the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate when the data source of the shared information is determined to be a correct data source; a first determination subunit, used to determine that the check transaction data has passed verification when the target hash value is detected to be the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate; and a second determination subunit, used to determine that the check transaction data has failed verification when the target hash value is detected to be different from the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate.

[0150] Optionally, the blockchain-based check transaction data processing device further includes: a third acquisition unit for acquiring user information provided by the user from the check transaction terminal through an application server; a first generation unit for generating a registered account based on the user information provided by the user; and a second generation unit for generating a master key, user key, and public key corresponding to the registered account.

[0151] Optionally, the second generation unit includes: a first acquisition subunit, used to acquire the generator and order of the bijective group, wherein the generator represents the set of elements that generate the entire bijective group, and the order represents the total number of elements in the bijective group; a selection subunit, used to randomly select a first value, a second value, and a third value, wherein the first value, the second value, and the third value are different values; a first generation subunit, used to generate a master key based on the first value, the second value, and the generator; a second generation subunit, used to generate a user key based on the generator, the third value, and the first value; and a third generation subunit, used to generate a public key based on the generator, the order, the first value, and the second value.

[0152] Optionally, the blockchain-based check transaction data processing device further includes: a consensus unit, used to perform peer-to-peer consensus operations between the blockchain node servers of the target financial institution and the blockchain node servers of other financial institutions, wherein the consensus operation is used to reach consensus on check transaction data in multiple stages; and a storage unit, used to save the operation results of the consensus operation into the blockchain blocks.

[0153] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer-readable storage medium, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described blockchain-based check transaction data processing method.

[0154] According to another aspect of the embodiments of this application, an electronic device is also provided, wherein the electronic device includes one or more processors and a memory, the memory being used to store one or more programs, wherein when one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to perform the above-described blockchain-based check transaction data processing method.

[0155] According to another aspect of the embodiments of this application, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the above-described blockchain-based check transaction data processing method.

[0156] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0157] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0158] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

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

[0160] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0161] If the integrated unit is implemented as 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 this application, in essence, 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0162] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A blockchain-based method for processing check transaction data, characterized in that, include: Receive check transaction data uploaded by the application server through the blockchain node server of the target financial institution; A binary tree shared path is generated based on the check transaction data. The binary tree shared path is used to record the blockchain scenario information when the blockchain node server of the target financial institution and the blockchain node servers of other financial institutions share the check transaction data. The other financial institutions are financial institutions in the blockchain network other than the target financial institution. Based on the scene identifier on the blockchain and the path information of the binary tree shared path, the check transaction data is populated with data values ​​to obtain the target data; The target data, the hash value corresponding to the root node of the shared path of the binary tree, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution are uploaded to the blockchain for notarization to obtain a blockchain certificate. The blockchain certificate is sent to the blockchain node server of the other financial institution, whereby the blockchain node server of the other financial institution is used to verify the received check transaction data based on the blockchain certificate.

2. The method according to claim 1, characterized in that, Before sending the blockchain certificate to the blockchain node server of the other financial institution, the method further includes: The physical addresses of the blockchain node servers of other financial institutions and the requests initiated by the blockchain node servers of other financial institutions to obtain the check transaction data are obtained through the blockchain node servers of the target financial institution. Gaussian noise is added to the physical address and the acquisition request to generate an interference dataset; The data in the disturbance dataset is modified by changing the target model over time.

3. The method according to claim 2, characterized in that, The process of determining the target model includes: Obtain the user dataset corresponding to the x-th physical address and the user dataset corresponding to the y-th physical address, wherein the x-th physical address and the y-th physical address are different physical addresses; The user dataset corresponding to the xth physical address is split into a first user set and a first interest set; The user dataset corresponding to the y-th physical address is split into a second user set and a second interest set; The first interest set and the second interest set are integrated into a target interest set, wherein the product of the target interest set and the first user set has a similarity greater than a preset threshold with the user dataset corresponding to the xth physical address, and the product of the target interest set and the second user set has a similarity greater than the preset threshold with the user dataset corresponding to the yth physical address. The target model is determined based on the target interest set.

4. The method according to claim 1, characterized in that, After sending the blockchain certificate to the blockchain node server of the other financial institution, the method further includes: Through the blockchain node server of the other financial institution, shared information is obtained based on the blockchain certificate, wherein the shared information includes: the blockchain scenario identifier to be confirmed, the blockchain scenario data serial number, the institution identifier of the target financial institution, and the signature information of the target financial institution; Determine the target binary tree shared path generated in the blockchain scenario corresponding to the blockchain scenario identifier; The target hash value corresponding to the root node of the target binary tree shared path is determined based on the blockchain scenario data serial number to be confirmed. The public key information of the target financial institution recorded on the blockchain is determined based on the institution identifier of the target financial institution; The check transaction data is verified based on the target hash value and the public key information.

5. The method according to claim 4, characterized in that, Verification of the check transaction data based on the target hash value and the public key information includes: Verify the signature information of the target financial institution in the shared information based on the public key information; Based on the verification result of the signature information, determine whether the data source of the shared information is a correct data source; If the data source of the shared information is determined to be the correct data source, it is checked whether the target hash value is the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate; If the target hash value is found to be the same as the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, the check transaction data is determined to have passed verification. If the target hash value is found to be different from the hash value corresponding to the root node of the binary tree shared path recorded in the blockchain certificate, it is determined that the check transaction data has failed verification.

6. The method according to claim 1, characterized in that, Before receiving check transaction data uploaded by the application server through the blockchain node server of the target financial institution, the method further includes: The application server obtains user information provided by the user from the check transaction terminal. Generate a registered account based on the user information provided by the user; Generate a master key, user key, and public key corresponding to the registered account.

7. The method according to claim 6, characterized in that, Generate a master key, user key, and public key corresponding to the registered account, including: Obtain the generator and order of a bijective group, wherein the generator represents the set of elements that generate the entire bijective group, and the order represents the total number of elements in the bijective group. Randomly select a first value, a second value, and a third value, wherein the first value, the second value, and the third value are different values; The master key is generated based on the first value, the second value, and the generator; The user key is generated based on the generator, the third value, and the first value. The public key is generated based on the generator, the order, the first value, and the second value.

8. The method according to claim 1, characterized in that, Before sending the blockchain certificate to the blockchain node server of the other financial institution, the method further includes: The blockchain node server of the target financial institution and the blockchain node servers of other financial institutions perform peer-to-peer consensus operations, wherein the consensus operations are used to reach a consensus on the check transaction data in multiple stages. The results of the consensus operation are saved to a block in the blockchain.

9. A blockchain-based check transaction data processing device, characterized in that, include: The receiving unit is used to receive check transaction data uploaded by the application server through the blockchain node server of the target financial institution; The first processing unit is configured to generate a binary tree shared path based on the check transaction data through the blockchain node server of the target financial institution. The binary tree shared path is used to record blockchain scenario information when the blockchain node server of the target financial institution shares the check transaction data with the blockchain node servers of other financial institutions. The other financial institutions are financial institutions in the blockchain network other than the target financial institution. The data filling unit is used to fill the check transaction data with data values ​​according to the scene identifier on the blockchain and the path information of the binary tree shared path to obtain the target data; The second processing unit is used to upload the target data, the hash value corresponding to the root node of the shared path of the binary tree, the serial number identifier of the check transaction data, the institution identifier of the target financial institution, and the signature information of the target financial institution to the blockchain for notarization, so as to obtain a blockchain certificate. A sending unit is configured to send the blockchain credential to the blockchain node server of the other financial institution, wherein the blockchain node server of the other financial institution is configured to verify the received check transaction data based on the blockchain credential.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device containing the computer-readable storage medium performs the blockchain-based check transaction data processing method according to any one of claims 1 to 8.

11. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the blockchain-based check transaction data processing method according to any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the blockchain-based check transaction data processing method according to any one of claims 1 to 8.

Images