A channel data sharing method and system

Abstract

The application discloses a channel data sharing method and system, wherein the reservation data is encrypted by using the channel company node public key to obtain a first encrypted string, the first encrypted string is uploaded to the service provider node, the service provider node writes the first encrypted string into a block of the alliance chain to obtain a first block address, and the reservation data is stored in the alliance chain in the form of the first encrypted string, so that the reservation data is prevented from being leaked. Therefore, other channel companies cannot contact the customers, and the situation that multiple channel companies reserve the same customer is reduced. The second encrypted string, the second block address and the data except the customer information in the visit data sent by the developer node are received. If the second encrypted string exists in the block corresponding to the second block address, the customer information in the reservation data and the data except the customer information in the visit data are encrypted by using the developer node public key to obtain a third encrypted string. If the third encrypted string is the same as the second encrypted string, the customer corresponding to the visit data is the customer corresponding to the reservation data.

Description

Technical Field

[0001] This application relates to the field of blockchain technology, and more specifically, to a method and system for sharing channel data. Background Technology

[0002] With the development of the times, business activities are no longer limited to the internal operations of units, enterprises, or organizations. More and more businesses rely on cooperation among multiple participants. Take the real estate industry as an example: Channel management is frequently used in real estate sales. Real estate developers cooperate with channel companies. The channel companies identify potential buyers and report their information to the developers, generating a registration form. When a customer arrives at the sales office, they are registered, generating a visitor's slip. The developer compares the information in the registration form and the visitor's slip to determine which customers were referred by the channel company. Once a transaction is completed, the real estate developer settles the commission with the channel company according to pre-agreed rules.

[0003] The registration forms provided by channel companies to developers record customers' names, phone numbers, and other information. However, these forms may be leaked, allowing other channel companies to contact customers using their phone numbers to sell properties. In this situation, multiple channel companies may have registered the same customer, making it impossible for the developer to determine which channel company the customer belongs to. Summary of the Invention

[0004] In view of this, this application provides a channel data sharing method and system to solve the problem that in existing channel data sharing methods, customer information is leaked on the reporting form, resulting in the developer being unable to determine which channel company the customer belongs to when multiple channel companies report the same customer.

[0005] To achieve the above objectives, the following solution is proposed:

[0006] A channel data sharing method, applied to channel company nodes, includes:

[0007] Generate reporting data, which includes customer information;

[0008] The reported data is encrypted using the public key of the channel company node to obtain the first encrypted string;

[0009] The first encrypted string is uploaded to the service provider node, so that the service provider node can write the first encrypted string into a block in the consortium blockchain according to a preset rule, thereby obtaining the address of the first block storing the first encrypted string. The consortium blockchain includes the channel company node, the developer node, and the service provider node.

[0010] Receive the first block address sent by the service provider node;

[0011] The system receives the second block address, the second encrypted string, and data other than customer information from the incoming visit data sent by the developer node, and determines whether the second encrypted string exists in the block corresponding to the second block address. The second encrypted string is obtained by the developer node encrypting the incoming visit data generated by the developer node using the developer's public key. The incoming visit data includes customer information.

[0012] If the second encrypted string exists in the block corresponding to the second block address, the developer node public key is used to encrypt the customer information in the reported data and the data other than the customer information in the visit data to obtain the third encrypted string.

[0013] If the third encryption string is the same as the second encryption string, the first block address, the first encryption string, and the reporting data are sent to the developer node. After determining that the first encryption string exists in the block corresponding to the first block address, the developer node uses the public key of the channel company node to encrypt the reporting data to obtain a fourth encryption string. The developer node then determines whether the reporting data of the channel company node is valid by judging whether the first encryption string and the fourth encryption string are the same.

[0014] Preferably, before encrypting the reporting data using the channel company's node public key to obtain the first encrypted string, the method further includes:

[0015] Add a first random salt value to the reported data;

[0016] The first random salt value is sent to the developer node so that the developer node can add the first random salt value to the reporting data after receiving the reporting data.

[0017] Preferably, it further includes:

[0018] Randomly generate virtual reporting data, which includes virtual identifiers and virtual customer information;

[0019] The virtual reporting data is encrypted using the public key of the channel company node to obtain the first virtual encrypted string;

[0020] The first virtual encryption string is uploaded to the service provider node, so that the service provider node can write the first virtual encryption string into the block corresponding to the first block address according to the preset rules.

[0021] Preferably, the random generation of virtual reporting data includes:

[0022] Obtain the number of reporting data generated by the channel company node in the previous virtual reporting data generation cycle of the current virtual reporting data generation cycle and the preset first parameter;

[0023] Based on the number of reported data and a preset first parameter, a virtual reported data generation probability that is inversely proportional to the number of reported data is obtained. The virtual reported data generation probability is greater than 0 and less than or equal to 1.

[0024] The current virtual reporting data generation cycle is divided into a second parameter number of virtual reporting data generation sub-cycles, where the second parameter is the sum of the number of reporting data and a preset first parameter.

[0025] In each virtual reporting data generation sub-cycle, a first random number is randomly generated, where the first random number is greater than 0 and less than or equal to 1;

[0026] Determine whether the first random number generated within each virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability.

[0027] If the probability is less than the first random number, then a virtual reporting data is generated within the virtual reporting data generation sub-cycle where the first random number is less than the virtual reporting data generation probability.

[0028] Preferably, before receiving the second block address, the second encrypted string, and data other than customer information from the incoming visit data sent by the developer node, the method further includes:

[0029] The data other than customer information in the reported data is sent to the developer node to notify the developer node that the channel company node has reported the customer.

[0030] Preferably, it further includes:

[0031] The system receives the address of the evidence data packet, the second random salt value, and the third block address of the block containing the evidence encryption string sent by the developer node. The evidence encryption string is an encryption string obtained by the developer node after encrypting the hash value of the evidence data packet using the developer node's public key. The hash value of the evidence data packet is a hash value calculated by the developer node after adding the second random salt value to the evidence data packet.

[0032] Access the address of the evidence data packet to obtain the evidence data packet;

[0033] Calculate the first hash value of the evidence data packet after adding the second random salt value;

[0034] The first hash value is encrypted using the developer node's public key to obtain the first encrypted evidence string;

[0035] Determine whether the encrypted evidence string in the block corresponding to the third block address is the same as the first encrypted evidence string.

[0036] A channel data sharing method, applied to developer nodes, includes:

[0037] Generate visitor data, which includes customer information;

[0038] The incoming data is encrypted using the developer node's public key to obtain a second encrypted string;

[0039] The second encrypted string is uploaded to the service provider node, so that the service provider node can write the second encrypted string into the block in the consortium blockchain according to the preset rules, thereby obtaining the address of the second block storing the second encrypted string. The consortium blockchain includes the channel company node, the developer node, and the service provider node.

[0040] Receive the second block address sent by the service provider node;

[0041] The second block address, the second encrypted string, and the data in the incoming visit data excluding customer information are sent to the channel company node. After the channel company node determines that the second encrypted string exists in the block corresponding to the second block address, it uses the developer node's public key to encrypt the customer information in the reported data and the data in the incoming visit data excluding customer information to obtain a third encrypted string, and determines whether the second encrypted string and the third encrypted string are the same.

[0042] Receive the first block address, the first encrypted string, and the reporting data sent by the channel company node, and determine whether the first encrypted string exists in the block corresponding to the first block address;

[0043] If so, the reported data is encrypted using the public key of the channel company node to obtain the fourth encrypted string;

[0044] Determine whether the fourth encrypted string is the same as the first encrypted string;

[0045] If they are the same, then the reported data is determined to be valid reported data.

[0046] Preferably, before encrypting the reporting data using the channel company's node public key to obtain the fourth encrypted string, the method further includes:

[0047] Receive the first random salt value sent by the channel company node;

[0048] The first random salt value is added to the reported data.

[0049] Preferably, it further includes:

[0050] Randomly generate virtual visitor data, which includes virtual identifiers and virtual customer information data;

[0051] The virtual visit data is encrypted using the developer node's public key to obtain a second virtual encrypted string;

[0052] The second virtual encryption string is uploaded to the service provider node so that the service provider node can write the second virtual encryption string into the block corresponding to the second block address according to the preset rules.

[0053] Preferably, the random generation of virtual visitor data includes:

[0054] Obtain the number of visitor data generated by the developer node in the previous virtual visitor data generation cycle of the current virtual visitor data generation cycle and the preset third parameter;

[0055] Based on the number of incoming data and a preset third parameter, a virtual incoming data generation probability that is inversely proportional to the number of incoming data is obtained. The virtual incoming data generation probability is greater than 0 and less than or equal to 1.

[0056] The current virtual visitor data generation cycle is divided into a fourth parameter number of virtual visitor data generation sub-cycles, where the fourth parameter is the sum of the number of visitor data and a preset third parameter.

[0057] In each virtual visitor data generation sub-cycle, a second random number is randomly generated. The second random number is greater than 0 and less than or equal to 1.

[0058] Determine whether the second random number generated within each virtual visitor data generation sub-cycle is less than the virtual visitor data generation probability.

[0059] If the probability is less than the second random number, then a virtual visitor data is generated within the virtual visitor data generation sub-cycle where the second random number is less than the virtual visitor data generation probability.

[0060] Preferably, it further includes:

[0061] Generate an evidence data package, which includes evidence of customer visits recorded by the developer node within a preset time period;

[0062] Store the evidence data packet to obtain the address of the evidence data packet that stores the evidence data packet;

[0063] A second random salt value is added to the evidence data packet and a hash value is calculated to obtain the hash value of the evidence data packet;

[0064] The hash value of the evidence data packet is encrypted using the developer node's public key to obtain the encrypted evidence string;

[0065] The encrypted evidence string is uploaded to the service provider node, so that the service provider node can write the encrypted evidence string into the block in the consortium blockchain according to the preset rules, thereby obtaining the address of the third block storing the encrypted evidence string.

[0066] Receive the third block address sent by the service provider node;

[0067] The evidence data packet address, the second random salt value, and the third block address are sent to the channel company node so that the channel company node can access the evidence data packet address, obtain the evidence data packet, add the second random salt value to the evidence data packet, calculate the first hash value, encrypt the first hash value using the developer node's public key to obtain the first evidence encryption string, and determine whether the first evidence encryption string is the same as the evidence encryption string in the block corresponding to the third block address.

[0068] A channel data sharing system, comprising: channel company nodes, developer nodes, and service provider nodes;

[0069] The channel company node is used to implement each step of the aforementioned channel data sharing method, the developer node is used to implement each step of the aforementioned channel data sharing method, and the service provider node is used to write the encrypted strings uploaded by the channel company node and the developer node into the block of the consortium blockchain according to preset rules.

[0070] As can be seen from the above technical solution, the channel data sharing method provided in this application involves the channel company node generating reporting data, then encrypting the reporting data using the channel company node's public key to obtain a first encrypted string. This first encrypted string is then uploaded to the service provider node, which writes it into a block in the consortium blockchain according to preset rules, obtaining a first block address storing the first encrypted string. The channel company node can receive the first block address sent by the service provider node. This application uses the channel company node's public key to encrypt the reporting data. To obtain customer information from the reporting data, decryption can only be performed using the private key corresponding to the channel company node's public key. Only the channel company node knows the private key corresponding to its public key, preventing customer information leakage. The channel company node can receive and judge the second encrypted string, the second block address, and data other than customer information from the visitor data sent by the developer node. The second encrypted string is obtained by the developer node encrypting the visitor data generated by the developer node using its public key. If the second encrypted string exists in the second block address, it proves that the developer node has entered the visitor data. Then, the developer node's public key is used to encrypt the customer information in the reported data and the data other than customer information in the visit data, resulting in a third encrypted string. If the third encrypted string is the same as the second encrypted string, it proves that the customer corresponding to the visit data generated by the developer node is the same customer corresponding to the reported data generated by the channel company node. The developer can only know the customer information after the customer visits, which can prevent the developer from contacting the customer and invalidating the customer reported by the channel company. At the same time, the reported data is stored in the consortium blockchain in the form of the first encrypted string to avoid the reported data being leaked and other channel companies contacting the customer, thus invalidating the customer reported by the channel company and reducing the situation where multiple channel companies report the same customer. After confirming that the customer corresponding to the visit data generated by the developer node is the same customer corresponding to the reported data generated by the channel company node, the channel company node will send the first block address, the first encrypted string, and the reported data to the developer node, so that the developer node can use the channel company node's public key to encrypt the reported data after confirming that the first encrypted string exists in the block corresponding to the first block address, to obtain a fourth encrypted string. Both the first and fourth encryption strings are obtained by encrypting the reported data using the channel company node's public key. Therefore, the developer node can determine whether the reported data of the channel company node is valid by judging whether the first and fourth encryption strings are the same.

[0071] Furthermore, blockchains include private chains, public chains, and consortium chains. This application uploads the encrypted first encrypted string to the consortium chain. Blockchains are tamper-proof, so the on-chain time cannot be altered. When multiple channel companies report the same customer, the developer can determine the channel company to which the customer belongs based on the on-chain time. Block generation in the consortium chain is jointly determined by pre-selected nodes. The consortium chain provided in this application uses service provider nodes as pre-selected nodes and developer nodes and channel company nodes as access nodes, reducing the number of pre-selected nodes, further improving block generation efficiency, and lowering the design complexity and service security requirements of the consortium chain. The consortium chain provided in this application can consist of multiple subnets; developers, channel companies, and service providers can form a subnet. Each company can have multiple nodes, and each node only connects to one subnet, ensuring data isolation in the consortium chain. Each node retains a copy of the data, ensuring data consistency. Attached Figure Description

[0072] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0073] Figure 1 This application provides a schematic diagram of the structure of a channel data sharing system.

[0074] Figure 2 An optional signaling flowchart for the channel data sharing method provided in the embodiments of this application;

[0075] Figure 3 A flowchart illustrating a channel data sharing method applied to channel company nodes, as provided in this application embodiment;

[0076] Figure 4 A flowchart illustrating another channel data sharing method applied to developer nodes, as provided in this application embodiment;

[0077] Figure 5 A schematic diagram of a channel data sharing device applied to a channel company node is provided in this application embodiment;

[0078] Figure 6 This is a schematic diagram of another channel data sharing device structure applied to a developer node, provided as an embodiment of this application. Detailed Implementation

[0079] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0080] First, combined Figure 1 This application introduces a channel data sharing system, such as... Figure 1 As shown, the system includes: channel company node 100, service provider node 200, and developer node 300. Among them, channel company node 100, service provider node 200, and developer node 300 can be terminals such as computers and cloud devices.

[0081] based on Figure 1 The system architecture shown is as follows: Figure 2 This application illustrates an optional signaling flow for a channel data sharing method provided in an embodiment of the present application, such as... Figure 2 As shown, the process may include:

[0082] Step S01: Channel company node 100 generates reporting data.

[0083] Specifically, the channel company needs to register its clients with the developer so that the developer can better serve the clients. Therefore, the channel company will generate client registration data, which may include: client information, viewing time, etc. Client information may include the client's mobile phone number, etc.

[0084] In step S02, the channel company node 100 uses the channel company node public key to encrypt the reported data and obtain the first encrypted string.

[0085] Specifically, to prevent the leakage of reported data and other channel companies from obtaining customer information and contacting customers, thus invalidating the customer reports submitted by channel company node 100, the generated reported data can be encrypted using the channel company node's public key to obtain the first encrypted string.

[0086] In step S03, the channel company node 100 uploads the first encrypted string to the service provider node 200.

[0087] Specifically, to prevent data tampering, the first encrypted string can be written into a block of the consortium blockchain consisting of channel company node 100, developer node 300, and service provider node 200. Service provider node 200 is designated as a pre-selected node, and it can write data into the block. Therefore, to write the first encrypted string into the block, it can be uploaded to service provider node 200.

[0088] In step S04, the service provider node 200 writes the first encrypted string into the block in the consortium blockchain according to the preset rules, and obtains the address of the first block storing the first encrypted string.

[0089] Specifically, service provider node 200 can write the first encrypted string uploaded by channel company node 100 within a certain period of time into a block in the consortium blockchain to obtain the address of the first block storing the first encrypted string.

[0090] In step S05, the service provider node 200 sends the first block address to the channel company node 100.

[0091] Specifically, after the service provider node 200 writes the first encrypted string into the block, it can send the address of the first block where the first encrypted string is stored to the channel company node 100, so that the channel company node can know the storage location of the first encrypted string.

[0092] Step S06: Developer node 300 generates visitor data.

[0093] Specifically, after a customer visits, developer node 300 records the customer's visit information. Developer node 300 can generate customer visit data, which includes customer information, visit time, etc.

[0094] In step S07, developer node 300 uses the developer node public key to encrypt the incoming data, obtaining a second encrypted string.

[0095] Specifically, to prevent the leakage of visitor data, the channel company needs to report naturally visiting customers. Developer node 300 can use the developer node's public key to encrypt the visitor data, obtaining a second encrypted string.

[0096] In step S08, developer node 300 uploads the second encrypted string to service provider node 200.

[0097] Specifically, to prevent incoming data from being tampered with, the second encrypted string can be written into a block of the consortium blockchain consisting of channel company node 100, developer node 300, and service provider node 200. Therefore, when developer node 300 wants to write the second encrypted string into a block, it can upload the second encrypted string to service provider node 200.

[0098] In step S09, the service provider node 200 writes the second encrypted string into the block in the consortium blockchain according to the preset rules, and obtains the address of the second block storing the second encrypted string.

[0099] Specifically, service provider node 200 can write the second encrypted string uploaded by developer node 300 within a certain period of time into a block in the consortium blockchain, thereby obtaining the address of the second block storing the second encrypted string.

[0100] In step S10, the service provider node 200 sends the address of the second block to the developer node 300.

[0101] Specifically, after the service provider node 200 writes the second encrypted string into the block, it can send the address of the second block where the second encrypted string is stored to the developer node 300, so that the developer node can know the storage location of the second encrypted string.

[0102] The execution order between steps S01-S05 and steps S06-S10 does not constitute a limitation of the present invention. The execution order between steps S01-S05 and steps S06-S10 can be adjusted. For example, steps S01-S05 can be executed in parallel with steps S06-S10, or they can be executed in any order.

[0103] In step S11, developer node 300 sends the second block address, the second encrypted string, and data other than customer information from the incoming visit data to channel company node 100.

[0104] Specifically, in order to prevent channel company node 100 from obtaining customer information reported by other channel companies based on the visit data, the developer node does not send the visit data to the channel company node, but instead sends the second block address, the second encrypted string, and the data in the visit data other than the customer information to the channel company node 100.

[0105] Step S12: Channel company node 100 determines whether the customer information in the visit data corresponds to a channel customer.

[0106] Specifically, the channel company node 100 can receive the second block address, the second encrypted string, and the data other than customer information in the incoming visit data sent by the developer node 300. It can then determine whether the second encrypted string exists in the block corresponding to the second block address. If the second encrypted string exists in the block corresponding to the second block address, the channel company node 100 can use the developer node's public key to encrypt the customer information in the reported data and the data other than customer information in the incoming visit data to obtain a third encrypted string. If the third encrypted string is the same as the second encrypted string, it proves that the customer information in the reported data is the same as the customer information in the incoming visit data, and determines that the customer corresponding to the customer information in the incoming visit data is a channel customer.

[0107] If the customer information in the visit data corresponds to a channel customer, then proceed to step S13 below; if the customer information in the visit data does not correspond to a channel customer, then send a prompt message to the developer node to prompt the developer node to confirm whether the sent data is correct.

[0108] In step S13, the channel company node 100 sends the first block address, the first encrypted string, and the reporting data to the developer node 300.

[0109] Specifically, after the channel company node 100 confirms that the developer node 300 has entered the customer visit data reported by the channel company node 100, in order to let the developer node confirm that the channel company node 100 has reported the customer corresponding to the customer information in the visit data, the channel company node 100 can send the first block address, the first encrypted string, and the reported data to the developer node 300.

[0110] Step S14: Developer node 300 determines whether the reported data is valid.

[0111] Specifically, developer node 300 can receive the first block address, the first encrypted string, and the reporting data sent by channel company node 100. It then determines whether the first encrypted string exists in the block corresponding to the first block address. If it does, developer node 300 can use the channel company node's public key to encrypt the reporting data, obtaining a fourth encrypted string. By comparing the first and fourth encrypted strings, it determines whether the reporting data from channel company node 100 is valid.

[0112] If they are the same, it proves that the data reported by channel company node 100 is valid, and the following step S15 can be executed; if they are different, it proves that the data reported by channel company node 100 is invalid, and a prompt message can be sent to channel company node 100 to prompt channel company node 100 to confirm whether the reported data sent is correct.

[0113] In step S15, the developer node 300 confirms that the reported data is valid.

[0114] This application provides a channel data sharing method in which channel company nodes and developer nodes upload encrypted strings to service provider nodes. The service provider nodes, acting as pre-selected nodes, write the encrypted strings into blocks on a consortium blockchain according to preset rules. The consortium blockchain includes channel company nodes and developer nodes. Blockchains include private blockchains, public blockchains, and consortium blockchains. Block generation in a consortium blockchain is jointly determined by the pre-selected nodes. The consortium blockchain provided in this application uses service provider nodes as pre-selected nodes and developer nodes and channel company nodes as access nodes, reducing the number of pre-selected nodes and further improving block generation efficiency.

[0115] Next, combined Figure 3 This application introduces the channel data sharing method provided from the perspective of channel company node 100, such as... Figure 3 As shown, the method includes:

[0116] Step S21: Generate reporting data.

[0117] Step S22: Use the public key of the channel company node to encrypt the reported data to obtain the first encrypted string.

[0118] The steps S21-S22 described above correspond one-to-one with steps S01-S02 in the aforementioned embodiments. Please refer to the foregoing description for details, which will not be repeated here.

[0119] Step S23: Upload the first encrypted string to the service provider node so that the service provider node can write the first encrypted string into the block in the consortium blockchain according to the preset rules, and obtain the address of the first block storing the first encrypted string.

[0120] Specifically, considering the possibility of malicious tampering with the initial encrypted string, and given that blockchains possess tamper-proof characteristics (including private, public, and consortium blockchains), the initial encrypted string can be written into a block of the consortium blockchain to prevent data tampering. This generates a consortium blockchain with participating channel company nodes, developer nodes, and service provider nodes. Service provider nodes can write the initial encrypted string uploaded by the channel company nodes into blocks of the consortium blockchain according to the upload time. This yields the address of the first block storing the initial encrypted string. Therefore, after obtaining the initial encrypted string, it can be uploaded to the service provider nodes.

[0121] Step S24: Receive the first block address sent by the service provider node.

[0122] Specifically, considering that the channel company node needs to know the storage location of the first encrypted string, after the service provider node obtains the first block address, it can send the first block address to the channel company node. Upon receiving the first block address from the service provider node, the channel company node can then determine the storage location of the first encrypted string.

[0123] Step S25: Receive the second block address, the second encrypted string, and data other than customer information from the incoming visit data sent by the developer node.

[0124] Specifically, after receiving a customer, the developer can generate customer visit data, which includes customer information, affiliated channel company information, etc. To facilitate verification by the channel company nodes to ensure the customer information in the reported data matches the customer information in the visit data generated by the developer nodes, the channel company nodes can receive the second block address, the second encrypted string, and all data from the visit data except for the customer information sent by the developer nodes. The second encrypted string is obtained by the developer nodes encrypting the visit data using their public key, and the second block address is obtained by uploading the second encrypted string to the service provider nodes, which then write the second encrypted string into the consortium blockchain according to preset rules.

[0125] Step S26: Determine whether the second encrypted string exists in the block corresponding to the second block address.

[0126] Specifically, considering that the second block address, the second encrypted string, and data other than customer information in the incoming data may be tampered with during transmission, it is advisable to first verify whether the second encrypted string exists in the block corresponding to the second block address. If it exists, it proves that the correct incoming data was written in the block corresponding to the second block address.

[0127] If the second encrypted string exists in the block corresponding to the second block address, then proceed to step S27 below; if the second encrypted string does not exist in the block corresponding to the second block address, then send a prompt message to the developer node to indicate that the second encrypted string does not exist in the block corresponding to the second block address sent by the developer node.

[0128] Step S27: Use the developer node's public key to encrypt the customer information in the reported data and the data other than the customer information in the visitor data to obtain the third encrypted string.

[0129] Specifically, to ensure that the data sent by the developer node, excluding customer information, has not been tampered with, the following encryption steps are taken: If the data sent by the developer node is from a channel customer reported by the channel company node, then the customer information in the incoming data is identical to the customer information in the reported data. The second encryption string is obtained by the developer node using its public key. Therefore, the channel company node can use the developer node's public key to encrypt both the customer information in the reported data and the data in the incoming data excluding customer information, resulting in a third encryption string.

[0130] Step S28: Determine whether the third encrypted string is the same as the second encrypted string.

[0131] Specifically, the third encrypted string is obtained by encrypting the customer information in the reported data and the data other than the customer information in the visiting data using the developer node's public key; the second encrypted string is obtained by encrypting the visiting data using the developer node's public key. Since both the third and second encrypted strings are encrypted using the developer node's public key, if the third encrypted string is the same as the second encrypted string, it proves that the customer information in the visiting data is the same as the customer information in the reported data.

[0132] If the third encrypted string is the same as the second encrypted string, then proceed to step S29 below; if the third encrypted string is different from the second encrypted string, then send a prompt message to the developer node to prompt the developer node to confirm whether the sent data is correct.

[0133] Step S29: Send the first block address, the first encrypted string, and the reporting data to the developer node.

[0134] Specifically, after the channel company node confirms that the developer has entered the correct visit data for the customer information corresponding to the reported customer information, it can send the first block address, the first encrypted string, and the reported data to the developer node. The developer node, after confirming that the first encrypted string exists in the block corresponding to the first block address, uses the channel company node's public key to encrypt the reported data, obtaining a fourth encrypted string. It then determines the validity of the channel company node's reported data by comparing the first and fourth encrypted strings.

[0135] The channel data sharing method provided in this application involves a channel company node generating reporting data, then encrypting the data using its public key to obtain a first encrypted string. This first encrypted string is then uploaded to a service provider node, which writes it into a block in the consortium blockchain according to preset rules, resulting in a first block address storing the first encrypted string. The channel company node can receive this first block address from the service provider node. This application uses the channel company node's public key to encrypt the reporting data; to obtain customer information from the reporting data, decryption is only possible using the private key corresponding to the channel company node's public key. Only the channel company node knows the private key corresponding to its public key, preventing customer information leakage. The channel company node can receive and judge the second encrypted string, the second block address, and data other than customer information from the incoming visit data sent by the developer node. The second encrypted string is obtained by the developer node encrypting the incoming visit data generated by the developer node using its public key. If the second encrypted string exists in the second block address, it proves that the developer node has entered the incoming visit data. Then, the developer node's public key is used to encrypt the customer information in the reported data and the data other than customer information in the visit data, resulting in a third encrypted string. If the third encrypted string is the same as the second encrypted string, it proves that the customer corresponding to the visit data generated by the developer node is the same customer corresponding to the reported data generated by the channel company node. The developer can only know the customer information after the customer visits, which can prevent the developer from contacting the customer and invalidating the customer reported by the channel company. At the same time, the reported data is stored in the consortium blockchain in the form of the first encrypted string to avoid the reported data being leaked and other channel companies contacting the customer, thus invalidating the customer reported by the channel company and reducing the situation where multiple channel companies report the same customer. After confirming that the customer corresponding to the visit data generated by the developer node is the same customer corresponding to the reported data generated by the channel company node, the channel company node will send the first block address, the first encrypted string, and the reported data to the developer node, so that the developer node can use the channel company node's public key to encrypt the reported data after confirming that the first encrypted string exists in the block corresponding to the first block address, to obtain a fourth encrypted string. Both the first and fourth encryption strings are obtained by encrypting the reported data using the channel company node's public key. Therefore, the developer node can determine whether the reported data of the channel company node is valid by judging whether the first and fourth encryption strings are the same.

[0136] Furthermore, blockchains include private chains, public chains, and consortium chains. This application uploads the encrypted first encrypted string to the consortium chain. Blockchains are tamper-proof, so the on-chain time cannot be altered. When multiple channel companies report the same customer, the developer can determine the channel company to which the customer belongs based on the on-chain time. Block generation in the consortium chain is jointly determined by pre-selected nodes. The consortium chain provided in this application uses service provider nodes as pre-selected nodes and developer nodes and channel company nodes as access nodes, reducing the number of pre-selected nodes, further improving block generation efficiency, and lowering the design complexity and service security requirements of the consortium chain. The consortium chain provided in this application can consist of multiple subnets; developers, channel companies, and service providers can form a subnet. Each company can have multiple nodes, and each node only connects to one subnet, ensuring data isolation in the consortium chain. Each node retains a copy of the data, ensuring data consistency.

[0137] In this embodiment of the application, before encrypting the reported data using the public key of the channel company node to obtain the first encrypted string in step S22, the following steps S30-S31 can also be performed.

[0138] Step S30: Add the first random salt value to the reported data.

[0139] Specifically, customer information may contain information such as customer phone numbers that can be obtained through iteration. Therefore, in order to prevent other channel companies from obtaining this information through iteration, a first random salt value can be added to the reported data, and then the reported data can be encrypted using the public key of the channel company node to obtain the first encrypted string.

[0140] Step S31: Send the first random salt value to the developer node.

[0141] Specifically, because the developer node needs to verify the validity of the reported data, it needs to encrypt the reported data to obtain a third encrypted string. Furthermore, it needs to determine whether the third encrypted string is the same as the first encrypted string, and the reported data corresponding to the first encrypted string has a first random salt value added to it. Therefore, the first random salt value also needs to be sent to the developer node so that the developer node can add the first random salt value to the reported data upon receiving it.

[0142] Before encrypting the reported data using the public key of the channel company node, this application embodiment adds a random salt value to the reported data, further reducing the possibility that other channel company nodes may obtain customer mobile phone numbers and other information by traversing through the data.

[0143] Considering that channel company nodes may not want other nodes in the consortium blockchain to know the true amount of reporting data generated by their nodes in order to protect the privacy of the reported data, this application embodiment, based on the channel data sharing method provided in the foregoing embodiments, may also perform the following steps S32-S34.

[0144] Step S32: Randomly generate virtual reporting data.

[0145] Specifically, to conceal the quantity of generated reporting data, in addition to generating the actual reporting data, random virtual reporting data can also be generated to obfuscate the quantity. This virtual reporting data includes virtual identifiers and virtual customer information. The virtual identifier is used to identify data as virtual reporting data.

[0146] Step S33: Use the public key of the channel company node to encrypt the virtual reporting data to obtain the first virtual encrypted string.

[0147] Step S34: Upload the first virtual encryption string to the service provider node so that the service provider node can write the first virtual encryption string into the block corresponding to the first block address according to the preset rules.

[0148] The steps S33-S34 described above correspond one-to-one with steps S22-S23 in the previous embodiments. Please refer to the above description for details, which will not be repeated here.

[0149] In this embodiment, during the generation of reporting data, virtual reporting data is randomly generated. This virtual reporting data is then encrypted using the channel company node's public key to obtain a first virtual encrypted string. This first virtual encrypted string is uploaded to the service provider node, which then writes it into the block corresponding to the first block address according to preset rules. At this point, the block corresponding to the first block address contains both the first encrypted string obtained from encrypting the reporting data and the first virtual encrypted string obtained from encrypting the virtual reporting data. Other nodes cannot determine the actual amount of reporting data generated by the channel company node based on the number of encrypted strings in the block.

[0150] This application embodiment describes step S32, the process of randomly generating virtual reporting data, the process including:

[0151] Step S321: Obtain the number of reporting data generated by the channel company node in the previous virtual reporting data generation cycle of the current virtual reporting data generation cycle and the preset first parameter.

[0152] Specifically, a first parameter and a virtual reporting data generation cycle can be preset, and the number of reporting data generated by the channel company node in the previous virtual reporting data generation cycle can be obtained. For example, the first parameter can be set to m1, the virtual reporting data generation cycle to T1, and the number of reporting data to n1.

[0153] Step S322: Calculate the virtual reporting data generation probability based on the number of reported data and the preset first parameter, which is inversely proportional to the number of reported data.

[0154] Specifically, to prevent an excessive number of virtual reporting data entries from affecting the actual reporting data, a virtual reporting data generation probability that is inversely proportional to the number of reporting data entries can be calculated based on the first parameter and the number of reporting data entries. This probability is greater than 0 and less than or equal to 1. For example, the virtual reporting data generation probability p1 can be calculated using p1 = m1 / (m1 + n1).

[0155] Step S323: Divide the current virtual reporting data generation cycle into a second parameter number of virtual reporting data generation sub-cycles.

[0156] Specifically, the number of reported data and the first parameter can be added together to obtain the second parameter. The current virtual reported data generation cycle can be divided into the second parameter number of virtual reported data generation sub-cycles. For example, after calculating the second parameter (m1+n1), the virtual reported data generation cycle T1 is divided into (m1+n1) virtual reported data generation sub-cycles t1, where t1 = T1 / (m1+n1).

[0157] Step S324: Randomly generate a first random number within each virtual reporting data generation sub-cycle.

[0158] Specifically, since the number of virtual reporting data generated within the current virtual reporting data generation cycle cannot be determined, in order to determine whether virtual reporting data is generated within each virtual reporting data generation sub-cycle based on the virtual reporting data generation probability, a first random number greater than 0 and less than or equal to 1 can be randomly generated within each virtual reporting data generation sub-cycle.

[0159] Step S325: Determine whether the first random number generated within each virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability.

[0160] Specifically, the generation probability of virtual reporting data can be determined based on the magnitude of the first random number and the virtual reporting data generation probability. Therefore, it is necessary to determine whether the first random number generated in each virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability. The virtual reporting data generation probability in the current virtual reporting data generation cycle is inversely proportional to the number of reporting data generated in the previous virtual reporting data generation cycle. The more reporting data there is, the lower the virtual reporting data generation probability, and the less likely the generated first random number is to be less than the virtual reporting data generation probability.

[0161] If it is less than, then proceed to step S326 below.

[0162] Step S326: Generate a virtual reporting data within a virtual reporting data generation sub-cycle where the first random number is less than the virtual reporting data generation probability.

[0163] Specifically, when the first random number generated within a certain virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability, a virtual reporting data is generated within that virtual reporting data generation sub-cycle.

[0164] This application embodiment calculates the virtual reporting data generation probability, which is inversely proportional to the number of reporting data generated by channel company nodes in the previous virtual reporting data generation cycle. The current virtual reporting data generation cycle is divided into a second parameter number of virtual reporting data generation sub-cycles. A first random number is randomly generated in each virtual reporting data generation sub-cycle. When the first random number generated in a virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability, a virtual reporting data entry is generated in that sub-cycle. The more reporting data generated, the fewer virtual reporting data entries are generated. This not only obscures the number of generated reporting data entries but also prevents the generation of too many virtual reporting data entries from affecting the actual reporting data.

[0165] In this embodiment of the application, before receiving the second block address, the second encrypted string, and data other than customer information in the incoming data sent by the developer node in step S25, the following step S35 may also be performed.

[0166] Step S35: Send the data other than customer information from the reported data to the developer node.

[0167] Specifically, in order to notify the developer node that the customer has been reported, the channel company node can send the data other than the customer information in the reported data to the developer node.

[0168] In this embodiment, the data other than customer information in the reported data is sent to the developer node. After receiving the data other than customer information in the reported data, the developer node can determine that the channel company node has reported the customer, and the developer node can prepare to receive the customer.

[0169] Based on the channel data sharing method provided in the foregoing embodiments, the embodiments of this application may also perform the following steps S36-S40.

[0170] Step S36: Receive the address of the evidence data packet, the second random salt value, and the third block address of the block containing the evidence encryption string sent by the developer node.

[0171] Specifically, after the developer node receives a customer reported by the channel company, it can generate an evidence data packet for the customer reception and send the evidence data packet address, the second random salt value, and the third block address of the block containing the evidence encryption string to the channel company node. The evidence encryption string is the encrypted string obtained by the developer node encrypting the hash value of the evidence data packet using its public key. The hash value of the evidence data packet is the hash value calculated by the developer node after adding the second random salt value to the evidence data packet.

[0172] Step S37: Access the evidence data packet address and obtain the evidence data packet.

[0173] Specifically, the channel company node can access the evidence data packet address and obtain the evidence data packet stored in the evidence data packet address.

[0174] Step S38: Calculate the first hash value of the evidence data packet after adding the second random salt value.

[0175] Specifically, because the evidence encryption string in the block corresponding to the third block address is obtained by encrypting the hash value of the evidence data packet after the developer node adds a second random salt value using the developer node's public key, the channel company node can calculate the first hash value of the evidence data packet after adding the second random salt value sent by the developer node to the evidence data packet.

[0176] Step S39: Encrypt the first hash value using the developer node's public key to obtain the first evidence encrypted string.

[0177] Specifically, because the evidence encryption string in the block corresponding to the third block address is obtained by the developer node using its public key, in order to better determine whether the evidence encryption string in the block corresponding to the third block address has been tampered with, the channel company node can use the developer node's public key to encrypt the first hash value to obtain the first evidence encryption string.

[0178] Step S40: Determine whether the encrypted evidence string in the block corresponding to the third block address is the same as the encrypted evidence string of the first block.

[0179] Specifically, since both the first evidence encryption string and the evidence encryption string in the block corresponding to the third block address are encrypted using the developer node's public key, it's possible to determine whether the evidence data packet has been tampered with by comparing the evidence encryption string in the block corresponding to the third block address with the first evidence encryption string. If they are the same, it proves that the evidence data packet has not been tampered with, and the evidence data packet provided by the developer is valid evidence. If they are different, it proves that the evidence data packet has been tampered with, and a notification message is sent to the developer node to prompt it to check whether the evidence data packet has been tampered with.

[0180] In this embodiment, after receiving the evidence data packet address, the second random salt value, and the third block address of the block containing the encrypted evidence string from the developer node, the channel company node accesses the evidence data packet address, obtains the evidence data packet, calculates the first hash value of the evidence data packet after adding the second random salt value, encrypts the first hash value using the developer node's public key, and obtains the first encrypted evidence string. Then, it determines whether the encrypted evidence string in the block corresponding to the third block address is the same as the first encrypted evidence string. If they are the same, it proves that the evidence data packet has not been tampered with; if they are different, it proves that the evidence data packet has not been tampered with, thus enhancing the persuasiveness of the evidence.

[0181] Combination Figure 4 This paper introduces the channel data sharing method provided in this application from the perspective of developer node 300, such as... Figure 4 As shown, the method includes:

[0182] Step S41: Generate visitor data.

[0183] Step S42: Encrypt the incoming data using the developer node's public key to obtain the second encrypted string.

[0184] The steps S41-S42 described above correspond one-to-one with steps S06-S07 in the previous embodiments. Please refer to the above description for details, which will not be repeated here.

[0185] Step S43: Upload the second encrypted string to the service provider node so that the service provider node can write the second encrypted string into the block in the consortium blockchain according to the preset rules, and obtain the address of the second block storing the second encrypted string.

[0186] Specifically, considering the possibility of malicious tampering with the second encrypted string, and given the tamper-proof nature of blockchain (which includes private, public, and consortium blockchains), the second encrypted string can be written into a block of the consortium blockchain to prevent data tampering. This generates a consortium blockchain with nodes from the channel company, developer, and service provider. Service provider nodes can write the second encrypted string uploaded by the developer node into a block of the consortium blockchain according to the upload time. This yields the address of the second block storing the second encrypted string. Therefore, after obtaining the second encrypted string, it can be uploaded to the service provider node.

[0187] Step S44: Receive the second block address sent by the service provider node.

[0188] Specifically, considering that the developer node needs to know the storage location of the second encrypted string, the service provider node, after obtaining the second block address, can send the second block address to the developer node. Once the channel company node receives the second block address sent by the service provider node, it can then determine the storage location of the second encrypted string.

[0189] Step S45: Send the second block address, the second encrypted string, and the data in the incoming visit data other than customer information to the channel company node.

[0190] Specifically, after a customer visits, the second block address, the second encrypted string, and all data in the visit data except for the customer information can be sent to the channel company node. This allows the channel company node to verify whether the customer information in the reported data matches the customer information in the visit data generated by the developer node. The channel company node verification process has been described in steps S26-S28 of the aforementioned embodiment and will not be repeated here.

[0191] Step S46: Receive the first block address, the first encrypted string, and the reporting data sent by the channel company node.

[0192] Specifically, after the channel company node confirms that the customer information in the incoming visit data corresponds to the customer information in the reported data, it will send the first block address, the first encrypted string, and the reported data to the developer node. Therefore, the developer node can receive the first block address, the first encrypted string, and the reported data sent by the channel company node.

[0193] Step S47: Determine whether the first encrypted string exists in the block corresponding to the first block address.

[0194] Specifically, considering that the developer node needs to determine whether the channel company node has actually reported the customer, the developer node can first verify whether the first encrypted string exists in the block corresponding to the first block address. If it exists, it proves that the reported data has been written into the block corresponding to the first block address, meaning that the channel company node has reported the customer.

[0195] If it exists, proceed to step S48 below; if it does not exist, send a prompt message to the channel company node to indicate that the first encrypted string does not exist in the block corresponding to the first block address sent by the channel company node.

[0196] Step S48: Use the public key of the channel company node to encrypt the reported data to obtain the fourth encrypted string.

[0197] Specifically, the first encrypted string is obtained by encrypting the reporting data using the channel company node's public key. Therefore, in order to determine whether the reporting data generated by the channel company node is valid, the developer node can use the channel company node's public key to encrypt the reporting data sent by the channel company node, resulting in the fourth encrypted string.

[0198] Step S49: Determine whether the fourth encrypted string is the same as the first encrypted string.

[0199] Specifically, both the fourth and first encryption strings are obtained by encrypting the reporting data using the channel company node's public key. When the fourth encryption string is the same as the first encryption string, it proves that the reporting data sent by the channel company node is the reporting data generated by the channel company node. Therefore, if the fourth encryption string is the same as the first encryption string, it can be determined that the reporting data is valid; if the fourth encryption string is different from the first encryption string, a prompt message can be sent to the channel company node to prompt it to confirm whether the correct reporting data has been sent.

[0200] In this embodiment of the application, before step S48, where the reporting data is encrypted using the channel company node public key to obtain the fourth encrypted string, the following may also be included:

[0201] Step S50: Receive the first random salt value sent by the channel company node.

[0202] Specifically, considering that the channel company node may add a first random salt value to the reported data before encrypting it, and then send the first random salt value to the developer node, the developer node can receive the first random salt value sent by the channel company node.

[0203] Step S51: Add the first random salt value to the reported data.

[0204] Specifically, a first random salt value can be added to the reported data, and then the reported data can be encrypted using the public key of the channel company node to obtain a fourth encrypted string.

[0205] Considering that developer nodes may not want other nodes in the consortium blockchain to know the actual amount of data they generate in order to protect the privacy of incoming data, this application embodiment, based on the channel data sharing method provided in the foregoing embodiments, may further include:

[0206] Step S52: Randomly generate virtual visitor data.

[0207] Specifically, to conceal the number of generated visitor data, in addition to generating real visitor data, randomly generated virtual visitor data can also be used to obfuscate the quantity of visitor data. Virtual visitor data includes virtual identifiers and virtual customer information. The false identifier is used to identify data as virtual visitor data.

[0208] Step S53: Use the developer node's public key to encrypt the virtual incoming data to obtain the second virtual encrypted string.

[0209] Step S54: Upload the second virtual encryption string to the service provider node so that the service provider node can write the second virtual encryption string into the block corresponding to the second block address according to the preset rules.

[0210] The steps S53-S54 described above correspond one-to-one with steps S42-S43 in the previous embodiments. Please refer to the above description for details, which will not be repeated here.

[0211] This application embodiment describes the process of randomly generating virtual visitor data in step S52, as follows:

[0212] Step S521: Obtain the number of visitor data generated by the developer node in the previous virtual visitor data generation cycle and the preset third parameter.

[0213] Step S522: Calculate the virtual visitor data generation probability based on the number of visitor data and the preset third parameter. The virtual visitor data generation probability is inversely proportional to the number of visitor data.

[0214] Step S523: Divide the current virtual visitor data generation cycle into a fourth parameter number of virtual visitor data generation sub-cycles.

[0215] Specifically, the fourth parameter is the sum of the number of incoming data and the preset third parameter.

[0216] Step S524: Randomly generate a second random number within each virtual visitor data generation sub-cycle.

[0217] Specifically, the second random number is greater than 0 and less than or equal to 1.

[0218] Step S525: Determine whether the second random number generated within each virtual visitor data generation sub-cycle is less than the virtual visitor data generation probability.

[0219] If it is less than, then proceed to step S526 below.

[0220] Step S526: Generate a virtual visitor data within a virtual visitor data generation sub-cycle where the second random number is less than the virtual visitor data generation probability.

[0221] The process of generating virtual visitor data in steps S521-S526 above corresponds one-to-one with the process of generating virtual reporting data in steps S321-S326 in the aforementioned embodiment. For details, please refer to the foregoing description, which will not be repeated here.

[0222] Based on the channel data sharing method provided in the foregoing embodiments, this application embodiment may further include:

[0223] Step S55: Generate evidence data package.

[0224] Specifically, the developer node can package evidence of customer visits recorded by the developer node within a preset time period into an evidence data package. The evidence can be photos, videos, etc., of the customer visits.

[0225] Step S56: Store the evidence data packet and obtain the address of the stored evidence data packet.

[0226] Specifically, after obtaining the evidence data packet, the developer node stores the evidence data packet, which can be stored on a server, blockchain, etc., and obtains the evidence data packet address where the evidence data packet is stored.

[0227] Step S57: Add a second random salt value to the evidence data packet and calculate the hash value to obtain the hash value of the evidence data packet.

[0228] Specifically, to prevent the evidence data packet from being tampered with, the developer node can add a second random salt value to the evidence data packet and calculate the hash value to obtain the hash value of the evidence data packet.

[0229] Step S58: Use the developer node's public key to encrypt the hash value of the evidence data packet to obtain the encrypted evidence string.

[0230] Step S59: Upload the encrypted evidence string to the service provider node so that the service provider node can write the encrypted evidence string into the block in the consortium blockchain according to the preset rules, and obtain the address of the third block storing the encrypted evidence string.

[0231] The steps S58-S59 described above correspond one-to-one with steps S42-S43 in the aforementioned embodiments. Please refer to the foregoing description for details, which will not be repeated here.

[0232] Step S60: Send the evidence data packet address, the second random salt value, and the third block address to the channel company node.

[0233] Specifically, when a dispute arises between the developer node and the channel company node regarding customer ownership, the channel company node needs to verify whether the evidence data packet obtained by the developer node is valid evidence. Therefore, the developer node can send the evidence data packet address, the second random salt value, and the third block address to the channel company node. The process by which the channel company node determines whether the evidence data packet is valid evidence has been described in detail in steps S37-S40 of the aforementioned embodiment, and will not be repeated here.

[0234] In this embodiment, after obtaining evidence of a customer visit, the developer node packages the evidence into an evidence data packet. After obtaining the evidence data packet, a second random salt value is added to it, and the hash value of the evidence data packet is calculated. The hash value is then encrypted to obtain an encrypted evidence string. This encrypted evidence string is then written to a block in the consortium blockchain. In this embodiment, the developer node does not encrypt the evidence data packet before writing it to the consortium blockchain block; instead, it encrypts the hash value of the evidence packet before writing it to the block, thus improving the throughput of the consortium blockchain.

[0235] The channel data sharing device provided in the embodiments of this application is described below. The channel data sharing device described below and the channel data sharing method described above can be referred to in correspondence.

[0236] First, combined Figure 5 This section introduces channel data sharing devices applied to channel company nodes, such as... Figure 5 As shown, the channel data sharing device may include:

[0237] The reporting data generation unit 001 is used to generate reporting data, which includes customer information.

[0238] The first encryption unit 002 is used to encrypt the reported data using the public key of the channel company node to obtain the first encrypted string;

[0239] The first encrypted string uploading unit 003 is used to upload the first encrypted string to the service provider node, so that the service provider node can write the first encrypted string into the block in the consortium blockchain according to the preset rules, and obtain the first block address storing the first encrypted string. The consortium blockchain includes the channel company node, the developer node and the service provider node.

[0240] The first address receiving unit 004 is used to receive the first block address sent by the service provider node;

[0241] The incoming data receiving unit 005 is used to receive the second block address, the second encrypted string, and data other than customer information in the incoming data sent by the developer node.

[0242] The first judgment unit 006 is used to determine whether the second encryption string exists in the block corresponding to the second block address. The second encryption string is obtained by the developer node using the developer public key to encrypt the incoming data generated by the developer node. The incoming data includes customer information.

[0243] If the second encrypted string exists in the block corresponding to the second block address, then the steps of the second encryption unit described below are executed.

[0244] The second encryption unit 007 is used to encrypt the customer information in the reported data and the data other than the customer information in the visit data using the developer node public key to obtain a third encryption string;

[0245] The second judgment unit 008 is used to determine whether the third encrypted string is the same as the second encrypted string;

[0246] If the third encrypted string is the same as the second encrypted string, then the steps of the first sending unit described below are executed.

[0247] The first sending unit 009 is used to send the first block address, the first encrypted string, and the reporting data to the developer node, so that after the developer node determines that the first encrypted string exists in the block corresponding to the first block address, it uses the public key of the channel company node to encrypt the reporting data to obtain a fourth encrypted string, and determines whether the reporting data of the channel company node is valid by judging whether the first encrypted string and the fourth encrypted string are the same.

[0248] Optionally, the channel data sharing device may further include:

[0249] The first salt value calculation unit is used to add a first random salt value to the reporting data before the first encryption unit encrypts the reporting data using the channel company node public key to obtain the first encrypted string;

[0250] The second sending unit is used to send the first random salt value to the developer node, so that the developer node can add the first random salt value to the reporting data after receiving the reporting data.

[0251] Optionally, the channel data sharing device may further include:

[0252] A virtual reporting data generation unit is used to randomly generate virtual reporting data, which includes virtual identifiers and virtual customer information;

[0253] The first virtual data encryption unit is used to encrypt the virtual reporting data using the public key of the channel company node to obtain the first virtual encryption string;

[0254] The first virtual encryption string uploading unit is used to upload the first virtual encryption string to the service provider node, so that the service provider node can write the first virtual encryption string into the block corresponding to the first block address according to the preset rules.

[0255] Optionally, the virtual reporting data generation unit's process of randomly generating virtual reporting data may include:

[0256] Obtain the number of reporting data generated by the channel company node in the previous virtual reporting data generation cycle of the current virtual reporting data generation cycle and the preset first parameter;

[0257] Based on the number of reported data and a preset first parameter, a virtual reported data generation probability that is inversely proportional to the number of reported data is obtained. The virtual reported data generation probability is greater than 0 and less than or equal to 1.

[0258] The current virtual reporting data generation cycle is divided into a second parameter number of virtual reporting data generation sub-cycles, where the second parameter is the sum of the number of reporting data and a preset first parameter.

[0259] In each virtual reporting data generation sub-cycle, a first random number is randomly generated, where the first random number is greater than 0 and less than or equal to 1;

[0260] Determine whether the first random number generated within each virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability.

[0261] If the probability is less than the first random number, then a virtual reporting data is generated within the virtual reporting data generation sub-cycle where the first random number is less than the virtual reporting data generation probability.

[0262] Optionally, the channel data sharing device may further include:

[0263] The third sending unit is used to send the data other than customer information in the reporting data to the developer node before the incoming data receiving unit receives the second block address, the second encrypted string and the data other than customer information in the incoming data sent by the developer node, so as to prompt the developer node that the channel company node has reported the customer.

[0264] Optionally, the channel data sharing device may further include:

[0265] The evidence receiving unit is used to receive the address of the evidence data packet, the second random salt value, and the third block address of the block where the evidence encryption string is located, sent by the developer node. The evidence encryption string is an encryption string obtained by the developer node after encrypting the hash value of the evidence data packet using the developer node's public key. The hash value of the evidence data packet is a hash value calculated by the developer node after adding the second random salt value to the evidence data packet.

[0266] An evidence data packet acquisition unit is used to access the evidence data packet address and acquire the evidence data packet;

[0267] The first hash value calculation unit is used to calculate the first hash value of the evidence data packet after adding the second random salt value;

[0268] The first evidence encryption unit is used to encrypt the first hash value using the developer node's public key to obtain the first evidence encryption string;

[0269] The third judgment unit is used to determine whether the evidence encryption string in the block corresponding to the third block address is the same as the first evidence encryption string.

[0270] Next, combined Figure 6This section introduces the channel data sharing device applied to developer nodes, such as... Figure 6 As shown, the channel data sharing device may include:

[0271] Visitor data generation unit 011 is used to generate visit data, which includes customer information;

[0272] The third encryption unit 012 is used to encrypt the incoming data using the developer node public key to obtain a second encrypted string;

[0273] The second encrypted string uploading unit 013 is used to upload the second encrypted string to the service provider node, so that the service provider node can write the second encrypted string into the block in the consortium blockchain according to the preset rules, and obtain the address of the second block storing the second encrypted string. The consortium blockchain includes the channel company node, the developer node and the service provider node.

[0274] The second address receiving unit 014 is used to receive the second block address sent by the service provider node;

[0275] The fourth sending unit 015 is used to send the second block address, the second encryption string, and the data in the incoming visit data excluding customer information to the channel company node, so that after the channel company node determines that the second encryption string exists in the block corresponding to the second block address, it uses the developer node's public key to encrypt the customer information in the reporting data and the data in the incoming visit data excluding customer information to obtain a third encryption string, and determines whether the second encryption string and the third encryption string are the same.

[0276] The reporting data receiving unit 016 is used to receive the first block address, the first encrypted string, and the reporting data sent by the channel company node;

[0277] The fourth judgment unit 017 determines whether the first encrypted string exists in the block corresponding to the first block address;

[0278] If so, then perform the steps of the fourth encryption unit as described below.

[0279] The fourth encryption unit 018 is used to encrypt the reported data using the public key of the channel company node to obtain the fourth encryption string;

[0280] The fifth judgment unit 019 is used to determine whether the fourth encrypted string is the same as the first encrypted string;

[0281] If they are the same, then the reported data is determined to be valid reported data.

[0282] Optionally, the channel data sharing device may further include:

[0283] The first salt value receiving unit is used to receive a first random salt value sent by the channel company node before the fourth encryption unit encrypts the reporting data using the channel company node public key to obtain the fourth encrypted string.

[0284] The second salt value calculation unit adds the first random salt value to the reported data.

[0285] Optionally, the channel data sharing device may further include:

[0286] A virtual visitor data generation unit is used to randomly generate virtual visitor data, which includes virtual identifiers and virtual customer information data.

[0287] The second virtual data encryption unit is used to encrypt the virtual incoming data using the developer node's public key to obtain a second virtual encryption string;

[0288] The second virtual encryption string uploading unit is used to upload the second virtual encryption string to the service provider node, so that the service provider node can write the second virtual encryption string into the block corresponding to the second block address according to the preset rules.

[0289] Optionally, the virtual visitor data generation unit may include the following process for randomly generating virtual visitor data:

[0290] Obtain the number of visitor data generated by the developer node in the previous virtual visitor data generation cycle of the current virtual visitor data generation cycle and the preset third parameter;

[0291] Based on the number of incoming data and a preset third parameter, a virtual incoming data generation probability that is inversely proportional to the number of incoming data is obtained. The virtual incoming data generation probability is greater than 0 and less than or equal to 1.

[0292] The current virtual visitor data generation cycle is divided into a fourth parameter number of virtual visitor data generation sub-cycles, where the fourth parameter is the sum of the number of visitor data and a preset third parameter.

[0293] In each virtual visitor data generation sub-cycle, a second random number is randomly generated. The second random number is greater than 0 and less than or equal to 1.

[0294] Determine whether the second random number generated within each virtual visitor data generation sub-cycle is less than the virtual visitor data generation probability.

[0295] If the probability is less than the second random number, then a virtual visitor data is generated within the virtual visitor data generation sub-cycle where the second random number is less than the virtual visitor data generation probability.

[0296] Optionally, the channel data sharing device may further include:

[0297] An evidence generation unit is used to generate an evidence data package, which includes evidence of customer visits recorded by the developer node within a preset time period.

[0298] An evidence storage unit is used to store the evidence data packet and obtain the address of the evidence data packet storing the evidence data packet;

[0299] The second hash value calculation unit is used to add a second random salt value to the evidence data packet and calculate the hash value to obtain the hash value of the evidence data packet;

[0300] The second evidence encryption unit is used to encrypt the hash value of the evidence data packet using the developer node's public key to obtain an encrypted evidence string;

[0301] An evidence encryption string uploading unit is used to upload the evidence encryption string to a service provider node, so that the service provider node can write the evidence encryption string into a block in the consortium blockchain according to a preset rule, thereby obtaining the address of the third block storing the evidence encryption string.

[0302] The third address receiving unit is used to receive the third block address sent by the service provider node;

[0303] The evidence sending unit is used to send the evidence data packet address, the second random salt value, and the third block address to the channel company node, so that the channel company node can access the evidence data packet address, obtain the evidence data packet, add the second random salt value to the evidence data packet, calculate the first hash value, encrypt the first hash value using the developer node's public key to obtain the first evidence encryption string, and determine whether the first evidence encryption string is the same as the evidence encryption string in the block corresponding to the third block address.

[0304] This application embodiment also provides a storage medium that can store a program suitable for execution by a processor, the program being used to implement various processing flows in the aforementioned channel data sharing scheme.

[0305] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0306] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0307] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for sharing channel data, characterized in that, Applied to channel company nodes, the methods include: Generate reporting data, which includes customer information; The reported data is encrypted using the public key of the channel company node to obtain the first encrypted string; The first encrypted string is uploaded to the service provider node, so that the service provider node can write the first encrypted string into a block in the consortium blockchain according to a preset rule, thereby obtaining the address of the first block storing the first encrypted string. The consortium blockchain includes the channel company node, the developer node, and the service provider node. Receive the first block address sent by the service provider node; The system receives the second block address, the second encrypted string, and data other than customer information from the incoming visit data sent by the developer node, and determines whether the second encrypted string exists in the block corresponding to the second block address. The second encrypted string is obtained by the developer node encrypting the incoming visit data generated by the developer node using the developer's public key. The incoming visit data includes customer information. If the second encrypted string exists in the block corresponding to the second block address, the developer node public key is used to encrypt the customer information in the reported data and the data other than the customer information in the visit data to obtain the third encrypted string. If the third encryption string is the same as the second encryption string, then the first block address, the first encryption string, and the reporting data are sent to the developer node. After determining that the first encryption string exists in the block corresponding to the first block address, the developer node uses the public key of the channel company node to encrypt the reporting data to obtain a fourth encryption string. The developer node then determines whether the reporting data of the channel company node is valid by judging whether the first encryption string and the fourth encryption string are the same.

2. The method according to claim 1, characterized in that, Before encrypting the reported data using the channel company's node public key to obtain the first encrypted string, the method further includes: Add a first random salt value to the reported data; The first random salt value is sent to the developer node so that the developer node can add the first random salt value to the reporting data after receiving the reporting data.

3. The method according to claim 1, characterized in that, Also includes: Randomly generate virtual reporting data, which includes virtual identifiers and virtual customer information; The virtual reporting data is encrypted using the public key of the channel company node to obtain the first virtual encrypted string; The first virtual encryption string is uploaded to the service provider node, so that the service provider node can write the first virtual encryption string into the block corresponding to the first block address according to the preset rules.

4. The method according to claim 3, characterized in that, The randomly generated virtual reporting data includes: Obtain the number of reporting data generated by the channel company node in the previous virtual reporting data generation cycle of the current virtual reporting data generation cycle and the preset first parameter; Based on the number of reported data and a preset first parameter, a virtual reported data generation probability that is inversely proportional to the number of reported data is obtained. The virtual reported data generation probability is greater than 0 and less than or equal to 1. The current virtual reporting data generation cycle is divided into a second parameter number of virtual reporting data generation sub-cycles, where the second parameter is the sum of the number of reporting data and a preset first parameter. In each virtual reporting data generation sub-cycle, a first random number is randomly generated, where the first random number is greater than 0 and less than or equal to 1; Determine whether the first random number generated within each virtual reporting data generation sub-cycle is less than the virtual reporting data generation probability. If the probability is less than the first random number, then a virtual reporting data is generated within the virtual reporting data generation sub-cycle where the first random number is less than the virtual reporting data generation probability.

5. The method according to claim 1, characterized in that, Before receiving the second block address, the second encrypted string, and data other than customer information from the incoming visit data sent by the developer node, the process also includes: The data other than customer information in the reported data is sent to the developer node to notify the developer node that the channel company node has reported the customer.

6. The method according to any one of claims 1-5, characterized in that, Also includes: The system receives the address of the evidence data packet, the second random salt value, and the third block address of the block containing the evidence encryption string sent by the developer node. The evidence encryption string is an encryption string obtained by the developer node after encrypting the hash value of the evidence data packet using the developer node's public key. The hash value of the evidence data packet is a hash value calculated by the developer node after adding the second random salt value to the evidence data packet. Access the address of the evidence data packet to obtain the evidence data packet; Calculate the first hash value of the evidence data packet after adding the second random salt value; The first hash value is encrypted using the developer node's public key to obtain the first encrypted evidence string; Determine whether the encrypted evidence string in the block corresponding to the third block address is the same as the first encrypted evidence string.

7. A method for sharing channel data, characterized in that, Applied to developer nodes, the methods include: Generate visitor data, which includes customer information; The incoming data is encrypted using the developer node's public key to obtain a second encrypted string; The second encrypted string is uploaded to the service provider node, so that the service provider node can write the second encrypted string into the block in the consortium blockchain according to the preset rules, thereby obtaining the address of the second block storing the second encrypted string. The consortium blockchain includes the channel company node, the developer node, and the service provider node. Receive the second block address sent by the service provider node; The second block address, the second encrypted string, and the data in the incoming visit data excluding customer information are sent to the channel company node. After the channel company node determines that the second encrypted string exists in the block corresponding to the second block address, it uses the developer node's public key to encrypt the customer information in the reported data and the data in the incoming visit data excluding customer information to obtain a third encrypted string, and determines whether the second encrypted string and the third encrypted string are the same. Receive the first block address, the first encrypted string, and the reporting data sent by the channel company node, and determine whether the first encrypted string exists in the block corresponding to the first block address; If so, the reported data is encrypted using the public key of the channel company node to obtain the fourth encrypted string; Determine whether the fourth encrypted string is the same as the first encrypted string; If they are the same, then the reported data is determined to be valid reported data.

8. The method according to claim 7, characterized in that, Before encrypting the reported data using the channel company's node public key to obtain the fourth encrypted string, the method further includes: Receive the first random salt value sent by the channel company node; The first random salt value is added to the reported data.

9. The method according to claim 7, characterized in that, Also includes: Randomly generate virtual visitor data, which includes virtual identifiers and virtual customer information data; The virtual visit data is encrypted using the developer node's public key to obtain a second virtual encrypted string; The second virtual encryption string is uploaded to the service provider node so that the service provider node can write the second virtual encryption string into the block corresponding to the second block address according to the preset rules.

10. The method according to claim 9, characterized in that, The randomly generated virtual visitor data includes: Obtain the number of visitor data generated by the developer node in the previous virtual visitor data generation cycle of the current virtual visitor data generation cycle and the preset third parameter; Based on the number of incoming visit data and a preset third parameter, a virtual incoming visit data generation probability that is inversely proportional to the number of incoming visit data is obtained. The virtual incoming visit data generation probability is greater than 0 and less than or equal to 1. The current virtual visitor data generation cycle is divided into a fourth parameter number of virtual visitor data generation sub-cycles, where the fourth parameter is the sum of the number of visitor data and a preset third parameter. In each virtual visitor data generation sub-cycle, a second random number is randomly generated. The second random number is greater than 0 and less than or equal to 1. Determine whether the second random number generated within each virtual visitor data generation sub-cycle is less than the virtual visitor data generation probability. If the probability is less than the second random number, then a virtual visitor data is generated within the virtual visitor data generation sub-cycle where the second random number is less than the virtual visitor data generation probability.

11. The method according to any one of claims 7-10, characterized in that, Also includes: Generate an evidence data package, which includes evidence of customer visits recorded by the developer node within a preset time period; Store the evidence data packet to obtain the address of the evidence data packet that stores the evidence data packet; A second random salt value is added to the evidence data packet and a hash value is calculated to obtain the hash value of the evidence data packet; The hash value of the evidence data packet is encrypted using the developer node's public key to obtain the encrypted evidence string; The encrypted evidence string is uploaded to the service provider node, so that the service provider node can write the encrypted evidence string into the block in the consortium blockchain according to the preset rules, and obtain the address of the third block storing the encrypted evidence string. Receive the third block address sent by the service provider node; The evidence data packet address, the second random salt value, and the third block address are sent to the channel company node so that the channel company node can access the evidence data packet address, obtain the evidence data packet, add the second random salt value to the evidence data packet, calculate the first hash value, encrypt the first hash value using the developer node's public key to obtain the first evidence encryption string, and determine whether the first evidence encryption string is the same as the evidence encryption string in the block corresponding to the third block address.

12. A channel data sharing system, characterized in that, The system includes: channel company nodes, developer nodes, and service provider nodes; The channel company node is used to implement each step of the channel data sharing method according to any one of claims 1-6, the developer node is used to implement each step of the channel data sharing method according to any one of claims 7-11, and the service provider node is used to write the encrypted strings uploaded by the channel company node and the developer node into the block of the consortium blockchain according to preset rules.

Images