Cross-border guarantee data processing method and device

Abstract

This application provides a cross-border guarantee data processing method and apparatus, relating to the field of blockchain technology, and applicable to the financial and other fields. The method includes: configuring corresponding shared parameter information for binary tree shared path modeling based on guarantee transaction data provided by a user to a first bank application server, through a blockchain node server associated with the first bank application server; calculating the corresponding binary tree shared path and shared guarantee data based on the shared parameter information; synchronizing and storing the binary tree shared path, the shared guarantee data, and the corresponding calculated binary tree root hash to a blockchain network constructed by multiple banks through corresponding blockchain node servers; obtaining the shared guarantee data from the blockchain network through a blockchain node server associated with a second bank application server; and providing the guarantee data to the second bank application server for guarantee credit processing.

Description

Technical Field

[0001] This application relates to the field of blockchain technology and can be applied to the financial and other fields, particularly a cross-border guarantee data processing method and apparatus. Background Technology

[0002] In recent years, with the further expansion of overseas engineering contracting, international trade, and overseas investment, the international guarantee business has developed rapidly, and the demand for cross-border guarantee services has been increasing. In the traditional bank guarantee process, after the bank issues the guarantee certificate according to the applicant's requirements, it mainly delivers the guarantee certificate to the beneficiary in two ways: one is to directly give the paper document to the applicant to take away and give it to the beneficiary; the other is to transmit it to the beneficiary's local bank via the SWIFT message system, where the local bank prints it and gives it to the local beneficiary or the applicant's local agent. For guarantee documents that require verification, the beneficiary will give the original guarantee document to the local bank, which will then send a verification message to the bank that issued the guarantee document to confirm its authenticity.

[0003] The current process has three main problems: First, the existing methods of transmitting guarantee documents, whether by letter or SWIFT message, always result in the guarantee document ultimately reaching the beneficiary client via letter. Paper media is easily damaged and poses a high risk of information leakage and tampering, resulting in poor security. Second, the current verification process for the authenticity of guarantee documents is very lengthy, taking more than 20 days from issuance to completion. Third, the SWIFT network is only accessible to SWIFT member institutions, making it vulnerable to sanctions and inaccessibility.

[0004] Furthermore, although the industry has digitized these guarantee documents into online systems, the data in these systems is easily altered and modified, easily forged, and untraceable, leading to a decline in the credibility of guarantee documents. This is especially true for cross-border and cross-institutional guarantee documents, as they are transmitted through internet channels, making electronic certificates vulnerable to modification by criminals. In cross-institutional data sharing processes, to ensure that the data ultimately obtained by the data requesting institution is consistent with the original data provided by the data provider, a blockchain consortium network is often established by the participating parties. The data provider institution uploads the data to be shared to the blockchain using a hash calculation data fingerprint. After the user provides the data to the data requesting institution in a portable form, the data requesting institution first verifies the consistency of the data by comparing the hash calculation data fingerprint with the fingerprint on the blockchain. In the process of cross-institutional data sharing, it is also necessary to take into account the privacy protection needs of data. Currently, there are two security issues with the technology of putting data fingerprints on the chain: First, because specific data items have fixed rules, the public disclosure of data hashes on the chain may lead to the risk of enumeration and deduction of the original data; Second, because the data is carried by users in a portable form for verification, the business needs privacy protection to both require the verification party to have the right to view the data fingerprints on the chain and not to publicly disclose the verification party. Summary of the Invention

[0005] The purpose of this application is to provide a method and apparatus for processing cross-border guarantee data. It utilizes blockchain technology to construct a consortium blockchain and stores cross-border guarantee data certificates on the chain, enabling information sharing, accelerating information flow, and connecting the processes of relevant parties in cross-border guarantee business. This improves the work efficiency of all parties, reduces costs such as fees and time, and ensures the security, transparency, and immutability of guarantee document data. Based on the business scenario, a set of corresponding shared data fields can be extracted for binary tree modeling, and the calculation path for verifying specific fields can be agreed upon. All participating parties generate public-private key pairs representing their institutional identity. The private key is kept by the participating parties as proof of their identity, while the public key is publicly disclosed on the chain 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 public disclosure of data on the chain, ensuring the privacy and security of on-chain data.

[0006] To achieve the above objectives, the cross-border guarantee data processing method provided in this application specifically includes: based on the guarantee transaction data provided by the user to the first bank's application server, configuring corresponding shared parameter information through a binary tree shared path modeling via a blockchain node server associated with the first bank's application server; calculating the corresponding binary tree shared path and shared guarantee data based on the shared parameter information; synchronizing the binary tree shared path, the shared guarantee data, and the corresponding calculated binary tree root hash to a blockchain network constructed by multiple banks through corresponding blockchain node servers; obtaining the shared guarantee data from the blockchain network through a blockchain node server associated with the second bank's application server; and providing the guarantee data to the second bank's application server for guarantee credit processing.

[0007] In the above-mentioned cross-border guarantee data processing method, optionally, the sharing parameter information configured by the blockchain node server associated with the first bank application server for binary tree shared path modeling based on the guarantee transaction data provided by the user to the first bank application server includes: obtaining the guarantee transaction data provided by the user through the first bank application server, storing the transaction elements of the guarantee transaction data to the first bank application server; and configuring the corresponding sharing parameter information by the blockchain node server associated with the first bank application server for binary tree shared path modeling of the transaction elements.

[0008] In the above-mentioned cross-border guarantee data processing method, optionally, storing the transaction elements of the guarantee transaction data to the first bank application server includes: identifying the guarantee transaction data using image recognition technology to obtain the transaction elements of the guarantee transaction data; retrieving element information stored in a preset database based on user information in the guarantee transaction data, verifying the element information with the transaction elements to obtain a verification result; and storing the transaction elements to the first bank application server based on the verification result.

[0009] In the above-mentioned cross-border guarantee data processing method, optionally, obtaining shared guarantee data in the blockchain network through the blockchain node server associated with the second bank application server includes: obtaining a guarantee query request provided by the user through the second bank application server; using a preset interference model to perform privacy encryption processing on the guarantee query request to generate a transaction query request through the blockchain node server associated with the second bank application server; and retrieving the corresponding shared guarantee data in the blockchain network according to the transaction query request.

[0010] In the above cross-border guarantee data processing method, optionally, retrieving the corresponding shared guarantee data from the blockchain network according to the transaction query request includes: retrieving the corresponding binary tree shared path, the shared guarantee data, and the binary tree root hash from the blockchain network according to the transaction query request; performing a consistency check on the binary tree root hash based on the shared guarantee data and the binary tree shared path; and decrypting the shared guarantee data according to the check result to obtain the shared guarantee data.

[0011] In the above-mentioned cross-border guarantee data processing method, optionally, generating a transaction query request by using a preset interference model to perform privacy encryption processing on the guarantee query request through the blockchain node server associated with the second bank application server further includes: generating an interference dataset by adding Gaussian noise to the guarantee query request and the data demander address corresponding to the guarantee query request; constructing a matrix factorization model based on the interference dataset using a multi-party secure computation method; and obtaining the interference model through the matrix factorization model.

[0012] In the above-mentioned cross-border guarantee data processing method, optionally, the process of generating a transaction query request by using a preset interference model to perform privacy encryption processing on the guarantee query request through the blockchain node server associated with the second bank application server further includes: obtaining node information of the blockchain node server associated with the first bank application server based on the guarantee data; verifying the node information through the blockchain node server associated with the second bank application server to obtain a verification result; and using the preset interference model to perform privacy encryption processing on the guarantee query request based on the verification result to generate a transaction query request.

[0013] This application also provides a cross-border guarantee data processing device, the device comprising: an input module, a binary tree generation module, and a sharing module; the input module is used to configure corresponding sharing parameter information by performing binary tree shared path modeling through a blockchain node server associated with the first bank application server based on the guarantee transaction data provided by the user to the first bank application server; the binary tree generation module is used to calculate the corresponding binary tree shared path and shared guarantee data based on the shared parameter information, and synchronize the binary tree shared path, the shared guarantee data, and the corresponding calculated binary tree root hash to a preset blockchain network; the sharing module is used to obtain the shared guarantee data from the blockchain network through the blockchain node server associated with the second bank application server, and provide the guarantee data to the second bank application server for guarantee credit processing.

[0014] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0015] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0016] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0017] The beneficial technical effects of this application are as follows: 1. Guarantee information is directly transmitted from the guaranteeing bank to the lending bank, ensuring accurate, effective, and fast information transmission, effectively reducing the time and cost of guarantee issuance. For the guarantee requester, there is no need to transfer paper guarantee certificates back and forth between the guarantee issuer and the guarantee certificate user, eliminating the physical location (cross-border) restrictions on certificate issuance and use. 2. Encryption, decryption, signature, binary tree modeling, and blockchain technologies are used to improve the existing cross-border guarantee data certificate issuance and use process, transforming the current offline process into a fully online process, improving the processing efficiency of all parties, and reducing the risk of guarantee data forgery. 3. Based on the business scenario, corresponding shared data field sets are extracted for binary tree modeling, and the calculation path for specific field verification is agreed upon. All participants generate public-private key pairs that represent their institutional identity. The private key is kept by the participant as proof of their identity, while the public key is publicly disclosed on the blockchain to all blockchain members, serving as the key support for data authentication request signing and verification. This effectively solves the hidden danger of enumerating and reversing the original data due to the public disclosure of data on the blockchain, ensuring on-chain data security. 4. The identity anonymity device 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 can infer the real-world identity of this virtual identity. This allows attackers to prove their authority is within the blockchain consortium while concealing their specific organization on the chain, thus protecting the privacy of the requesting client. Furthermore, this avoids the problems of traditional privacy protection methods that require limiting signature length, thereby limiting the number of ring members and compromising anonymity. Attackers can also analyze multiple transactions of a virtual identity through transaction graphs and other means to infer the real-world identity based on the correlation between transactions. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. In the drawings:

[0019] Figure 1 This is a flowchart illustrating a cross-border guarantee data processing method provided in an embodiment of this application;

[0020] Figure 2 This is a schematic diagram of a shared parameter information acquisition process provided in an embodiment of this application;

[0021] Figure 3A This is a schematic diagram of the field decomposition process provided in an embodiment of this application;

[0022] Figure 3B This is a schematic diagram of a binary tree computation path provided in an embodiment of this application;

[0023] Figure 4 This is a schematic diagram of the transaction element storage process provided in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the guarantee data acquisition process provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the interference model acquisition process provided in an embodiment of this application;

[0026] Figure 7 This is a schematic diagram of the warranty data verification process provided in one embodiment of this application;

[0027] Figure 8 This is a schematic diagram of the cross-border guarantee data processing device provided in an embodiment of this application;

[0028] Figure 9 This is a schematic diagram of the data terminal structure for a warranty certificate provided in an embodiment of this application;

[0029] Figure 10 This is a schematic diagram of a bank application server structure provided in an embodiment of this application;

[0030] Figure 11 This is a schematic diagram of a bank blockchain node server structure provided in an embodiment of this application;

[0031] Figure 12 This is a schematic diagram of a cross-border guarantee data processing method provided in an embodiment of this application;

[0032] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The following will describe in detail the implementation methods of this application with reference to the accompanying drawings and embodiments, so as to fully understand how this application uses technical means to solve technical problems and achieve technical effects, and to implement it accordingly. It should be noted that, as long as there is no conflict, the various embodiments and features in each embodiment of this application can be combined with each other, and the resulting technical solutions are all within the protection scope of this application.

[0034] Furthermore, 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, and 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.

[0035] Please refer to Figure 1 As shown, the cross-border guarantee data processing method provided in this application specifically includes:

[0036] S101, based on the escrow transaction data provided by the user to the first bank's application server, configures the corresponding shared parameter information by performing binary tree shared path modeling through the blockchain node server associated with the first bank's application server.

[0037] S102 calculates the corresponding binary tree shared path and shared guarantee data based on the shared parameter information, and synchronizes the binary tree shared path, the shared guarantee data and the corresponding calculated binary tree root hash to the blockchain network built by multiple banks through corresponding blockchain node servers.

[0038] S103 obtains shared guarantee data from the blockchain network through the blockchain node server associated with the second bank application server, and provides the guarantee data to the second bank application server for guarantee credit processing.

[0039] Through the above embodiments, the cross-border guarantee data processing method provided in this application can improve the existing cross-border guarantee data certificate issuance and usage process using technologies such as decryption, signature, binary tree modeling, and blockchain. This transforms the current offline process into a fully online process, improving processing efficiency for all parties and reducing the risk of guarantee data forgery. Binary tree modeling is performed by extracting corresponding shared data field sets based on the business scenario, and the calculation path for verifying specific fields is agreed upon. All participating parties generate public-private key pairs representing their institutional identity. The private key is kept by the participating parties as proof of their identity, while the public key is publicly disclosed on the blockchain to all blockchain members, serving as the key support for signing and verifying data authentication requests. This effectively solves the hidden danger of being able to enumerate and reverse-engineer the original data due to the public disclosure of data on the blockchain, ensuring the privacy and security of on-chain data. The specific implementation process of each step will be described in detail in subsequent embodiments and will not be elaborated here.

[0040] Please refer to Figure 2 As shown, in one embodiment of this application, based on the escrow transaction data provided by the user to the first bank's application server, the shared parameter information corresponding to the binary tree shared path modeling configuration performed by the blockchain node server associated with the first bank's application server includes:

[0041] S201 obtains the collateral transaction data provided by the user through the First Bank application server and stores the transaction elements of the collateral transaction data in the First Bank application server;

[0042] S202 configures the corresponding shared parameter information by performing binary tree shared path modeling on the transaction elements through the blockchain node server associated with the first bank application server.

[0043] In practice, configuring the binary tree shared path model for the transaction elements mainly involves generating and uploading the binary tree path of the scenario data to be shared to the blockchain, generating and uploading the root hash of the shared data binary tree, and generating shared data information that can be verified through the binary tree for users applying for data sharing. This module's processing of shared data on the blockchain effectively solves the potential risk of data being enumerated and deduced from the original data due to public disclosure on the blockchain, ensuring on-chain data privacy and security. The specific steps are as follows:

[0044] The newly added data-sharing business scenario type and the alliance institutions on business chain 1 agree on the data format, generate a binary tree calculation path, and store it on the blockchain for notarization. For example, the fields shared in scenario 1 are split into Data1, Data2, Data3, and Data4, and the calculation is performed layer by layer until the HashRoot, with each data point as a leaf. The information stored on the blockchain includes the scenario ID and the scenario binary tree calculation path information. See the reference for details. Figure 3A As shown, for a data sharing scenario with a designed binary tree computation path, the data provider on business chain 1 can directly upload the HashRoot of the shared data to the chain for notarization. That is, first, obtain the binary tree computation 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, calculate the uncle HashRoot, and upload the HashRoot and the signature information of the HashRoot by the data provider using its own identity-identifying private key information, as well as the transaction information of the data, to the chain for notarization.

[0045] When a user requests data from a data provider using their own data, the system generates a binary tree computation path for the requested data and its verification, based on the fields specified in the user's request. For example, if the user requests "Data1," the corresponding computation path would be Data1, Hash2, and Hash34. This means the shared information provided to the user includes the scene ID, scene data serial number, and data information (Data1, Hash2, and Hash34, etc.). Figure 3B (as shown) and the provider's identity ID, and the provider's signature information for the entire data packet using its own identity's private key information.

[0046] Please refer to Figure 4 As shown, in one embodiment of this application, storing the transaction elements of the collateral transaction data to the first bank application server includes:

[0047] S401 uses image recognition technology to identify the transaction elements of the collateral transaction data;

[0048] S402 retrieves the element information stored in the preset database based on the user information in the escrow transaction data, and verifies the element information with the transaction elements to obtain the verification result;

[0049] S403 stores the transaction elements to the first bank application server based on the verification result.

[0050] In practice, this embodiment mainly uses image recognition technology, namely OCR technology, to form the guarantee element information on the electronic document of the guarantee certificate into a string and save it in the guarantee database. It also compares the submitted guarantee data with the guarantee data in the bank application server database to verify its authenticity, thus preventing the intentional or unintentional submission of incorrect guarantee elements.

[0051] Please refer to Figure 5 As shown, in one embodiment of this application, the shared guarantee data obtained by the blockchain node server associated with the second bank application server in the blockchain network includes:

[0052] S501 obtains the guarantee query request provided by the user through the second bank application server;

[0053] S502 uses a preset interference model to perform privacy encryption processing on the guarantee query request through the blockchain node server associated with the second bank application server to generate a transaction query request.

[0054] S503 retrieves the corresponding shared guarantee data from the blockchain network based on the transaction query request.

[0055] Specifically, in practical work, this embodiment mainly protects the physical address of the data requester by adding Gaussian noise to the data packets such as the object address of the requester and the request data 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 by means of analyzing transaction graphs, etc., and inferring the real identity of this virtual identity in reality based on the correlation between transactions. This can prove that one's authority is within the blockchain alliance while not disclosing which institution on the chain one belongs to.

[0056] In one embodiment of this application, the process of generating a transaction query request by using a preset interference model to perform privacy encryption processing on the guarantee query request through a blockchain node server associated with the second bank application server further includes: obtaining node information of the blockchain node server associated with the first bank application server based on the guarantee data; verifying the node information through the blockchain node server associated with the second bank application server to obtain a verification result; and using the preset interference model to perform privacy encryption processing on the guarantee query request based on the verification result to generate a transaction query request. In this embodiment, the reliability of the information source is mainly verified through preset information or public / private keys and signature information of the node. Those skilled in the art can choose an appropriate verification method according to actual needs, and this application does not impose further limitations here.

[0057] For details, please refer to Figure 6 As shown, in one embodiment of this application, the process of generating a transaction query request by using a preset interference model to perform privacy encryption processing on the guarantee query request through the blockchain node server associated with the second bank application server further includes:

[0058] S601 generates an interference dataset by adding Gaussian noise to the guarantee query request and the data requester address corresponding to the guarantee query request;

[0059] S602 constructs a matrix factorization model based on the interference dataset using a multi-party secure computation method, and obtains the interference model through the matrix factorization model.

[0060] In practical applications, the principles of this information protection method and interference model are as follows:

[0061] 1. The demand-side 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;

[0062] 2. When the requesting party initiates the on-chain interaction device to obtain on-chain evidence information, it uses the private key corresponding to its own identity ID and the public key corresponding to the identity ID of other participants on the blockchain to sign.

[0063] 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 and site2 store their respective user datasets M. (1) and M (2) The user set of site1 is U (1) The interest set is V (1) The user set of site2 is U (2) The interest set is V (2) The user dataset then satisfies the following coupling formula:

[0064] M (1) ≈U (1) V (1) ;

[0065] M (2) ≈U (2) V (2) ;

[0066] Let V be the complete set of interests, satisfying:

[0067]

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

[0069] M( 1) ≈U( 1 V;

[0070] M( 2) ≈U(2)V;

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

[0072] 4. Generate a probability model, specifying... For the conditionally distributed observation dataset, in and V∈R D×J Construct a prior probability distribution model above:

[0073]

[0074] Where ρo denotes 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.

[0075] And so on, based on this, we can define For the conditionally distributed observation dataset, in and V∈R D×J A prior probability distribution model is constructed above.

[0076] 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:

[0077]

[0078]

[0079] in,

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

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

[0082] Where 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.

[0083] 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:

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

[0085] 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:

[0086]

[0087] in,

[0088]

[0089] Please refer to Figure 7 As shown, in one embodiment of this application, retrieving the corresponding shared guarantee data from the blockchain network according to the transaction query request includes:

[0090] S701 retrieves the corresponding binary tree shared path, shared guarantee data, and binary tree root hash from the blockchain network according to the transaction query request;

[0091] S702 performs a consistency check on the root hash of the binary tree data based on the shared guarantee data and the shared binary tree path, and decrypts the shared guarantee data based on the check result to obtain the shared guarantee data.

[0092] The main purpose of the above embodiments is to verify the integrity of the data and whether it has been tampered with. The specific implementation of the verification logic will be described in detail in subsequent embodiments, and will not be described in detail here.

[0093] This application also provides a cross-border guarantee data processing device, the device comprising: an input module, a binary tree generation module, and a sharing module; the input module is used to configure corresponding sharing parameter information by performing binary tree shared path modeling through a blockchain node server associated with the first bank application server based on the guarantee transaction data provided by the user to the first bank application server; the binary tree generation module is used to calculate the corresponding binary tree shared path and shared guarantee data based on the shared parameter information, and synchronize the binary tree shared path, the shared guarantee data, and the corresponding calculated binary tree root hash to a preset blockchain network; the sharing module is used to obtain the shared guarantee data from the blockchain network through the blockchain node server associated with the second bank application server, and provide the guarantee data to the second bank application server for guarantee credit processing.

[0094] Please refer to the details. Figure 8 As shown, in practical operation, the cross-border guarantee data processing device may include a guarantee certificate data terminal 1, a bank application server 2, a blockchain network 3, a bank blockchain node server 4, and a wireless / wired network 5. The guarantee certificate data terminal connects to the bank application server via the wireless / wired network; the bank application server connects to the bank blockchain node server via the wireless / wired network; and the bank blockchain node server connects to the bank blockchain node server via the wireless / wired network to form a blockchain network.

[0095] The aforementioned guarantee certificate data terminal is responsible for providing a user interface for bank tellers, receiving instructions from tellers to input and query guarantee certificate data, and transmitting user instructions to the bank's application server. See details below. Figure 2 .

[0096] The bank application server is responsible for processing the user instructions sent by the guarantee certificate data terminal. Based on the guarantee business data stored on the application server, it records and queries transaction details and account database tables. It also compares the guarantee certificate data sent by the guarantee certificate data terminal with the guarantee database data on the application server, as shown in Figure 3.

[0097] The aforementioned bank blockchain node server is a blockchain node server deployed on the blockchain network. It can handle transaction requests related to data flow, including the identity identifiers and public key information of data providers and data requesting institutions, as well as the ability to store and retrieve evidence using a binary tree root hash of guarantee business scenario process data. It can be deployed distributed across participating banks in the consortium or centrally managed and maintained. Transaction requests are initiated by the bank application server. Update transactions require consensus among all consensus nodes on the blockchain. During the consensus process, each blockchain node must receive consistent confirmation messages from 2f+1 other blockchain nodes to complete consensus. New block data is generated based on the data processed according to the contract logic, triggering the relevant guarantee business process after contract execution. Query transactions directly retrieve the corresponding world state data from the corresponding blockchain node without requiring consensus. See details. Figure 4 .

[0098] The blockchain network is composed of several bank blockchain node servers. The chain includes multiple blockchain nodes, all of which are member nodes of the business chain. Each member node is deployed with a smart contract for data security authentication and endorsement. The total number of blockchain nodes in the business chain is 3f+1, where f represents the number of fault-tolerant nodes that can be supported, with a minimum value of 1. Both requests and business requests use the PBFT Byzantine Fault Tolerance algorithm for consensus. A consensus request can only complete the current stage of consensus after each verification node in the business chain receives at least 2f+1 consistent confirmation messages from other verification nodes. Consensus is only successful after all three stages of consensus of the Byzantine Fault Tolerance algorithm are completed. Only then are system restart operation requests and business requests executed, and only then can the execution results be used as legitimate data to generate new blocks and be persisted.

[0099] The wireless / wired network mentioned refers to a wireless communication network or an Internet communication network provided by an operator.

[0100] Please refer to this again. Figure 9 As shown, the guarantee certificate data terminal includes: a guarantee information input module 11, a guarantee information query module 12, and a guarantee certificate scanning module 13.

[0101] The aforementioned guarantee information entry module allows bank tellers to input guarantee transaction information into the system through its interface. The guarantee information query module allows bank tellers to submit query commands to the bank server based on transaction details through its interface, and displays the query results returned by the bank application server. The guarantee certificate scanning module allows bank tellers to scan paper guarantee certificates into electronic files through its interface, and then upload the electronic files to the bank application server.

[0102] like Figure 10 As shown, the bank application server includes: a guarantee information registration module 21, a guarantee document processing module 22, and a guarantee data verification module 23.

[0103] The guarantee information registration module is responsible for recording guarantee transaction data submitted by each guarantee certificate data terminal. For query transactions, it queries the guarantee information database based on the submitted guarantee elements. For new guarantee data transactions, it registers the guarantee element data (e.g., opening date, beneficiary name, beneficiary address, guarantee text information, etc.) in the bank application server's database and sends a data synchronization request to the bank's blockchain node server to synchronize data with other bank blockchain node servers. The guarantee document processing module is responsible for using OCR technology to form the guarantee element information on the electronic guarantee certificate into a string and storing it in the guarantee database, and then uploading the electronic guarantee certificate to the blockchain. The guarantee data verification module is responsible for processing guarantee data verification transaction requests submitted by the terminals, comparing the submitted guarantee data with the guarantee data in the bank application server's database to verify its authenticity.

[0104] like Figure 11 As shown, the bank blockchain node server includes: a transaction consensus module 41, a transaction execution module 42, a binary tree data generation module 43, a data authentication module 44, an on-chain interaction device 45, and an identity anonymity device 46.

[0105] The transaction consensus module 41 is responsible for peer-to-peer consensus information interaction with all blockchain node servers in the blockchain and is the core module for completing transaction consensus. It achieves consensus on the transaction result, specifically through 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 receiving consistent confirmation messages from at least 2f+1 other transaction consensus nodes in the current stage, 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 for processing.

[0106] The transaction execution module 42 is responsible for executing smart contract requests and persisting the ledger. It saves the successful transaction information, transaction result information, and SeqNo of the block consensus completed by the transaction consensus module 121 into the block, records the transaction log and sends the block execution success event, performs strong consistency checks on the blockchain node 2 (block height, predecessor, current hash), and finally updates the world state information.

[0107] The binary tree data generation module 43 is responsible for processing the shared data between the data providers and demanders participating in the alliance, including generating verifiable shared data as a data provider.

[0108] The data authentication module 44 refers to the process by which a data requester, upon receiving shared data from a user, retrieves the binary tree path and the root hash root of the shared data binary tree from the blockchain to verify the authenticity of the data. When a user provides shared data to a data requester, the requester verifies the data according to the following steps:

[0109] First, obtain the shared information provided by the user: Scene ID, Scene data serial number, data information (Data1, Hash2, Hash34), Provider organization ID, and Provider signature information. Then, based on the Scene ID, obtain the corresponding binary tree calculation path for that scene; based on the Scene data serial number, obtain the corresponding binary tree root (HashRoot); and based on the Provider organization ID, obtain the on-chain provider organization's public key information. Second, verify the provider's signature information in the datagram using the provider organization's public key information. Successful verification indicates the data source is authentic. Finally, calculate HashRoot = Hash(Hash(Hash(Data1), Hash2), Hash34) = Hash(Hash(Hash1, Hash2), Hash34) = Hash(Hash12, Hash34) using the corresponding binary tree calculation path and data information. Compare this result with the obtained binary tree root (HashRoot) value. Consistent matching indicates the data information matches the source data and is authentic.

[0110] The on-chain interaction device 45 is responsible for completing 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.

[0111] The aforementioned anonymity device 46 is responsible for verifying the information stored on the blockchain by the data provider when the data requesting institution verifies the authenticity of the on-chain guaranteed data. The on-chain system needs to verify the alliance identity of the data requesting party. 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 is also a verifiability issue. In some practical applications, the verifier needs to confirm the identity of the real signer, and 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 issues, 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. There are also scalability issues; existing ring signature schemes may have limitations in scalability, such as difficulty adapting to large-scale blockchain networks.

[0112] To facilitate a clearer understanding of the processing flow of the cross-border guarantee data processing device provided in this application, the following will use actual business processing as an example to describe the above embodiments in detail. Those skilled in the art will understand that this example does not limit this application in any way.

[0113] Please refer to Figure 12 As shown, the processing flow of the cross-border guarantee data processing device is as follows:

[0114] S1201: A bank teller enters the relevant information of the guarantee transaction submitted by Company A through the input interface provided by the guarantee information entry module on the guarantee certificate data terminal of Bank A, and scans the paper guarantee certificate into an electronic file through the scanning interface provided by the guarantee certificate scanning module, and uploads the guarantee transaction related data to the application server of Bank A.

[0115] S1202: The guarantee information registration module of Bank A's application server records the guarantee transaction data sent by each guarantee certificate data terminal. The guarantee document processing module uses OCR technology to form the guarantee element information on the electronic document of the guarantee certificate into a string and save it in the guarantee database. The guarantee data verification module compares the sent guarantee data with the guarantee data in the bank's application server database to verify its authenticity.

[0116] S1203: The guarantee information registration module will register the guarantee element data (such as: opening date, beneficiary name, beneficiary address, guarantee text information, etc.) of the newly added guarantee data transaction in the database of the bank application server, and synchronize the data with the blockchain node server of Bank A.

[0117] S1204: 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 node server itself, while the identity public key is synchronized to all bank node servers on the blockchain network. The transaction execution module on Bank A's blockchain node server completes the execution of smart contract requests and the persistence of the ledger. 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 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.

[0118] S1205: The binary tree data generation module models the shared guarantee data using a binary tree sharing path. It fills in specific data values ​​for data that can be shared with other banks based on the on-chain scenario ID and binary tree path information. The calculated binary tree root hash, the data's serial number ID, the provider's institution ID, and the provider's institution ID's signature information are then uploaded to the blockchain for notarization. Bank A's blockchain node server synchronizes data with other banks' (including Banks B, C, and D) blockchain node servers.

[0119] S1206: Based on Company A's application, the teller of Bank D queries Company A's guarantee information query module through the guarantee certificate data terminal of Bank D. The query transaction request is submitted to the application server of Bank D. The application server of Bank D sends the guarantee data query transaction request, including the guarantee number, to the blockchain node server of Bank D.

[0120] S1207: The identity anonymization device of the D Bank blockchain node server protects the privacy of query transaction requests. By protecting the physical address of the data requester, Gaussian noise is added to the data packets such as the object address of the requester and the request data to generate interference dataset. At the same time, a training model is established to continuously train and change the interference dataset. This prevents attackers from analyzing multiple transaction information of a virtual identity by means of transaction graph analysis, and from inferring the real identity of this virtual identity in reality based on the correlation between transactions. This allows attackers to prove that their authority is within the blockchain alliance while not disclosing which institution on the chain they belong to.

[0121] S1208: The D Bank blockchain node server verifies the identity of the query transaction request data. That is, it uses the public key information of the bank institution stored on the blockchain to verify the signature information. If the verification is successful, it means that the transaction initiator is one of the legitimate participating institutions and has the right to obtain evidence on the chain. The corresponding binary tree path, the public key of the provider institution, and the binary tree root hash information are returned to the D Bank application server.

[0122] S1209: D Bank's application server uses the identity private key to verify the provider's signature information and the source of the shared data. Based on the binary tree calculation path obtained from on-chain forensics and the data sharing package, it calculates the binary tree root hash of the shared information and performs a consistency check with the binary tree root hash information obtained from on-chain forensics. If all the above information is verified, it proves that the authenticity of the shared information carried by the user can be guaranteed. The guarantee data is decrypted and restored, and the restored guarantee data is stored on the application server. The guarantee is displayed on D Bank's guarantee certificate data terminal to provide users with subsequent guarantee business services.

[0123] The beneficial technical effects of this application are as follows: 1. Guarantee information is directly transmitted from the guaranteeing bank to the lending bank, ensuring accurate, effective, and fast information transmission, effectively reducing the time and cost of guarantee issuance. For the guarantee requester, there is no need to transfer paper guarantee certificates back and forth between the guarantee issuer and the guarantee certificate user, eliminating the physical location (cross-border) restrictions on certificate issuance and use. 2. Encryption, decryption, signature, binary tree modeling, and blockchain technologies are used to improve the existing cross-border guarantee data certificate issuance and use process, transforming the current offline process into a fully online process, improving the processing efficiency of all parties, and reducing the risk of guarantee data forgery. 3. Based on the business scenario, corresponding shared data field sets are extracted for binary tree modeling, and the calculation path for specific field verification is agreed upon. All participants generate public-private key pairs that represent their institutional identity. The private key is kept by the participant as proof of their identity, while the public key is publicly disclosed on the blockchain to all blockchain members, serving as the key support for data authentication request signing and verification. This effectively solves the hidden danger of enumerating and reversing the original data due to the public disclosure of data on the blockchain, ensuring on-chain data security. 4. The identity anonymity device 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 can infer the real-world identity of this virtual identity. This allows attackers to prove their authority is within the blockchain consortium while concealing their specific organization on the chain, thus protecting the privacy of the requesting client. Furthermore, this avoids the problems of traditional privacy protection methods that require limiting signature length, thereby limiting the number of ring members and compromising anonymity. Attackers can also analyze multiple transactions of a virtual identity through transaction graphs and other means to infer the real-world identity based on the correlation between transactions.

[0124] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0125] This application also provides a computer-readable storage medium storing a computer program that performs the above-described methods.

[0126] This application also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the above-described method.

[0127] like Figure 13As shown, the electronic device 600 may also include: a communication module 110, an input unit 120, an audio processor 130, a display 160, and a power supply 170. It is worth noting that the electronic device 600 does not necessarily need to include these components. Figure 13 All components shown; in addition, the electronic device 600 may also include Figure 13 For components not shown, please refer to existing technologies.

[0128] like Figure 13 As shown, the central processing unit 100, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device. The central processing unit 100 receives inputs and controls the operation of various components of the electronic device 600.

[0129] The memory 140 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned failure-related information, and also store a program for executing that information. The central processing unit 100 may execute the program stored in the memory 140 to perform information storage or processing, etc.

[0130] Input unit 120 provides input to central processing unit 100. Input unit 120 may be, for example, a keypad or touch input device. Power supply 170 provides power to electronic device 600. Display 160 displays images and text. Display may be, for example, an LCD display, but is not limited thereto.

[0131] The memory 140 can be a solid-state memory, such as a read-only memory (ROM), random access memory (RAM), a SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROMs. The memory 140 can also be some other type of device. The memory 140 includes a buffer memory 141 (sometimes referred to as a buffer). The memory 140 may include an application / function storage unit 142 for storing application programs and function programs or processes for executing the operation of the electronic device 600 via the central processing unit 100.

[0132] The memory 140 may also include a data storage unit (data 143) for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit (driver 144) of the memory 140 may include various drivers for the electronic device's communication functions and / or for performing other functions of the electronic device (such as messaging applications, address book applications, etc.).

[0133] The communication module 110 is a transmitter / receiver 110 that transmits and receives signals via antenna 111. The communication module (transmitter / receiver) 110 is coupled to the central processing unit 100 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0134] Based on different communication technologies, multiple communication modules 110 can be configured in the same electronic device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication module (transmitter / receiver) 110 is also coupled to a speaker 131 and a microphone 132 via an audio processor 130 to provide audio output via the speaker 131 and receive audio input from the microphone 132, thereby enabling typical telecommunications functions. The audio processor 130 may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor 130 is coupled to a central processing unit 100, enabling on-device recording via the microphone 132 and on-device playback of stored audio via the speaker 131.

[0135] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0136] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0138] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0139] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of this application. It should be understood that the above descriptions are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for processing cross-border guarantee data, characterized in that, The method includes: Based on the escrow transaction data provided by the user to the First Bank application server, the corresponding shared parameter information is configured through the blockchain node server associated with the First Bank application server to perform binary tree shared path modeling. This includes: obtaining user-provided collateral transaction data through the First Bank application server, and storing the transaction elements of the collateral transaction data on the First Bank application server; configuring corresponding shared parameter information by performing binary tree shared path modeling on the transaction elements through a blockchain node server associated with the First Bank application server; wherein, storing the transaction elements of the collateral transaction data on the First Bank application server includes: identifying the collateral transaction data using image recognition technology to obtain the transaction elements of the collateral transaction data; retrieving element information stored in a preset database based on user information in the collateral transaction data, verifying the element information with the transaction elements to obtain a verification result; and storing the transaction elements on the First Bank application server based on the verification result; the image recognition technology is OCR technology, and the OCR technology is used to shape the collateral element information into... The information is stored as a string in the guarantee database; the guarantee element information is attached to the electronic document of the guarantee certificate; wherein, the binary tree shared path modeling configuration of the transaction elements involves generating and uploading the binary tree path of the scenario data to be shared, generating and uploading the root of the shared data binary tree, and generating shared data information that can be verified by the binary tree for users applying for data sharing; wherein, the newly added data sharing business scenario type and the alliance institutions on the business chain agree on the data format and generate a binary tree calculation path for on-chain storage, the information stored on the chain includes the scenario ID and the scenario binary tree calculation path information. For data sharing scenarios with a designed binary tree calculation path, the data provider on the business chain can directly upload the root of the shared data binary tree for on-chain storage, and after obtaining the scenario binary tree calculation path information from the chain, replace the specific field information of the leaf node with the specific shared data value; The corresponding binary tree shared path and shared guarantee data are calculated based on the shared parameter information. The binary tree shared path, the shared guarantee data, and the corresponding calculated binary tree root hash are then stored and synchronized to a blockchain network constructed by multiple banks through corresponding blockchain node servers. The shared guarantee data is obtained from the blockchain network through a blockchain node server associated with the second bank application server, and the guarantee data is provided to the second bank application server for guarantee credit processing. The process of obtaining the shared guarantee data from the blockchain network through the blockchain node server associated with the second bank application server includes: obtaining a guarantee query request provided by a user through the second bank application server; using a preset interference model to perform privacy encryption processing on the guarantee query request to generate a transaction query request through the blockchain node server associated with the second bank application server; retrieving the corresponding shared guarantee data from the blockchain network according to the transaction query request, including: retrieving the corresponding binary tree shared path, the shared guarantee data, and the binary tree root hash from the blockchain network according to the transaction query request; performing a consistency check on the binary tree root hash based on the shared guarantee data and the binary tree shared path; and decrypting the shared guarantee data based on the check result to obtain the shared guarantee data.

2. The cross-border guarantee data processing method according to claim 1, characterized in that, The transaction query request generated by the blockchain node server associated with the second bank application server using a preset interference model to perform privacy encryption processing on the guarantee query request also includes: An interference dataset is generated by adding Gaussian noise to the guarantee query request and the data requester address corresponding to the guarantee query request. Based on the interference dataset, a matrix factorization model is constructed using a multi-party secure computation method, and the interference model is obtained through the matrix factorization model.

3. The cross-border guarantee data processing method according to claim 1, characterized in that, The transaction query request generated by the blockchain node server associated with the second bank application server using a preset interference model to perform privacy encryption processing on the guarantee query request also includes: Based on the guarantee data, obtain the node information of the blockchain node server associated with the first bank application server; The verification result is obtained by authenticating the node information through the blockchain node server associated with the second bank application server; Based on the verification results, a preset interference model is used to perform privacy encryption processing on the guarantee query request to generate a transaction query request.

4. A cross-border guarantee data processing device, characterized in that, The device includes: an input module, a binary tree generation module, and a sharing module; The input module is used to configure corresponding shared parameter information for binary tree shared path modeling based on the collateral transaction data provided by the user to the first bank application server, through a blockchain node server associated with the first bank application server; wherein it is used to: obtain the collateral transaction data provided by the user through the first bank application server, and store the transaction elements of the collateral transaction data to the first bank application server; configure corresponding shared parameter information for binary tree shared path modeling of the transaction elements through a blockchain node server associated with the first bank application server; wherein storing the transaction elements of the collateral transaction data to the first bank application server includes: identifying the collateral transaction data to obtain the transaction elements of the collateral transaction data through image recognition technology; retrieving element information stored in a preset database based on the user information in the collateral transaction data, verifying the element information with the transaction elements to obtain a verification result; and storing the transaction elements to the first bank application server based on the verification result. The bank application server; the image recognition technology is OCR technology, which is used to form a string of guarantee element information and store it in the guarantee database; the guarantee element information is attached to the electronic document of the guarantee certificate; wherein, the binary tree shared path modeling configuration of the transaction elements is to generate a binary tree path and put it on the chain for the scenario data to be shared, generate the root of the shared data binary tree and put it on the chain, and generate shared data information that can be verified by the binary tree for users applying for data sharing; wherein, the newly added data sharing business scenario type and the alliance institutions on the business chain agree on the data format and generate a binary tree calculation path and put it on the chain for notarization, the notarized information includes scenario ID, scenario binary tree calculation path information, for data sharing scenarios with designed binary tree calculation paths, the data provider on the business chain can directly put the root of the shared data binary tree on the chain for notarization, and after obtaining the scenario binary tree calculation path information from the chain, replace the specific field information of the leaf node with the specific shared data value; The binary tree generation module is used to calculate the corresponding binary tree shared path and shared guarantee data based on the shared parameter information, and synchronize the binary tree shared path, the shared guarantee data and the corresponding calculated binary tree root hash to the preset blockchain network. The sharing module is used to obtain shared guarantee data from the blockchain network through a blockchain node server associated with the second bank application server, and to provide the guarantee data to the second bank application server for guarantee credit processing. The process of obtaining the shared guarantee data from the blockchain network through the blockchain node server associated with the second bank application server includes: obtaining a guarantee query request provided by a user through the second bank application server; using a preset interference model to perform privacy encryption processing on the guarantee query request to generate a transaction query request through the blockchain node server associated with the second bank application server; retrieving the corresponding shared guarantee data from the blockchain network according to the transaction query request, including: retrieving the corresponding shared guarantee data from the blockchain network according to the transaction query request, including: retrieving the corresponding binary tree shared path, the shared guarantee data, and the binary tree root hash from the blockchain network according to the transaction query request; performing a consistency check on the binary tree root hash based on the shared guarantee data and the binary tree shared path; and decrypting the shared guarantee data based on the check result to obtain the shared guarantee data.

5. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 3.

7. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 3.

Images