Data resource pushing method and system

Abstract

The invention provides a data resource pushing method and system, which can improve privacy protection and reduce the risk of privacy disclosure. The data resource pushing method comprises the following steps: storing a public key of a requester in a block chain system in a key-value pair form; when a requester generates a query request, the requester calculates a zero-knowledge proof challenge; sending the data of the zero-knowledge proof challenge and the parameters of the query request to a request receiver; and when the request receiver verifies that the identity of the requester is legal, the requester obtains response data fed back by the request receiver according to the parameters of the query request.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a data resource push method and system. Background Art

[0002] Amid the rapid development of blockchain technology, its decentralized, tamper-proof, transparent, and traceable nature has revolutionized finance, supply chains, the Internet of Things, and other fields. However, the openness and transparency of traditional blockchains conflict fundamentally with user privacy protection needs. For example, the public nature of blockchain ledgers makes all transaction records visible to all nodes in the network. In resource push scenarios, even with anonymous addresses (such as public key hashes), attackers can still perform correlation analysis, leading to data leaks and posing privacy risks. Summary of the Invention

[0003] In order to solve the above technical problems, the present invention is proposed. Embodiments of the present invention provide a data resource push method and system, which can improve privacy protection and reduce the risk of privacy leakage.

[0004] According to one aspect of the present invention, a data resource push method is provided, characterized in that the data resource push method includes: storing the public key of the requester in the form of a key-value pair in the blockchain system; when the requester generates a query request, the requester calculates a zero-knowledge proof challenge; sending the data of the zero-knowledge proof challenge and the parameters of the query request to the request receiver; when the request receiver verifies that the identity of the requester is legitimate, the requester obtains response data fed back by the request receiver based on the parameters of the query request.

[0005] In one embodiment, when a requesting party generates a query request, the requesting party calculates a zero-knowledge proof challenge, including: the requesting party generates a trusted random number based on the parameters of the query request and calculates a temporary private key; the requesting party calculates a challenge value through a preset hash algorithm based on the trusted random number, the public key and the parameters of the query request; the requesting party calculates a response value based on the challenge value, the temporary private key and the private key; wherein, sending the data of the zero-knowledge proof challenge and the parameters of the query request to the request recipient includes: sending the trusted random number, the response value and the parameters of the query request to the request recipient.

[0006] In one embodiment, the requesting party calculates a response value based on the challenge value, the temporary private key and the private key, including: the requesting party calculates the response value based on the challenge value, the temporary private key and the private key through Formula 1: z=r+c×sk Formula 1; in Formula 1, z represents the response value, r represents the temporary private key, c represents the challenge value, and sk represents the private key.

[0007] In one embodiment, when the request receiver verifies the legitimacy of the requester's identity, before the requester obtains the response data fed back by the request receiver based on the parameters of the query request, the data resource push method also includes: the request receiver calculates the challenge value based on the parameters of the query request; the request receiver verifies the validity of the zero-knowledge proof challenge through the trusted random number of the requester, the public key, the response value and the challenge value calculated by the request receiver; when the zero-knowledge proof challenge is determined to be valid, the request receiver verifies the legitimacy of the requester's identity.

[0008] In one embodiment, the request receiving party verifies the validity of the zero-knowledge proof challenge through the trusted random number of the requesting party, the public key, the response value and the challenge value calculated by the request receiving party, including: the request receiving party verifies the validity of the zero-knowledge proof challenge through the trusted random number of the requesting party, the public key, the response value and the challenge value calculated by the request receiving party through Formula 2: z×G=R+c×pkFormula 2; in Formula 2, z represents the response value, G represents the generator base point of the elliptic curve, R represents the trusted random number, c represents the challenge value calculated by the request receiving party, pk represents the public key of the requesting party, pk=sk×G, sk represents the private key; wherein, when the zero-knowledge proof challenge is determined to be valid, the request receiving party verifies the legitimacy of the identity of the requesting party, including: when the equality in Formula 2 holds, the request receiving party verifies the legitimacy of the identity of the requesting party.

[0009] In one embodiment, the data resource push method further includes: storing the target address of the requester in the blockchain system in the form of a key-value pair; wherein the key-value pair includes a service address number and a specific address of the requesting server; wherein, when the requester generates a query request, the requester generates a zero-knowledge proof challenge, including: when the requester generates a query request, the service address number is attached as a parameter in the query request, and the requester generates a zero-knowledge proof challenge.

[0010] In one embodiment, after the request recipient verifies that the identity of the requesting party is legitimate, the data resource push method further includes: performing a digest calculation on the original message of the requesting party to generate a first hash value of a fixed length; the requesting party encrypts the first hash value based on a private key to generate a digital signature; the request recipient receives the digital signature and decrypts the digital signature using the public key of the requesting party to obtain the first hash value; the request recipient calculates a second hash value; and when the first hash value is the same as the second hash value, it is determined that the original message has not been tampered with.

[0011] According to another aspect of the present invention, a data resource push system is provided, which is applicable to the data resource push method described in any one of the above embodiments. The data resource push system includes: a public key management module, which is used to store the public key of the requester in the form of a key-value pair in the blockchain system; a non-interactive zero-knowledge proof module, which is used for the requester to calculate the zero-knowledge proof challenge when the requester generates a query request; a sending module, which is used to send the data of the zero-knowledge proof challenge and the parameters of the query request to the request recipient; and a response processing module, which is used for the requester to obtain response data fed back by the request recipient based on the parameters of the query request when the request recipient verifies that the identity of the requester is legitimate.

[0012] In one embodiment, the data resource push system further includes: a push application address list management system for storing service address numbers and their corresponding request server addresses; and a routing module for forwarding query requests to a designated server.

[0013] In one embodiment, the data resource push system further includes: a cache module for implementing a response cache mechanism; a customized response module for providing customized response data format and content; and a smart contract module for automatically adjusting request routing according to the real-time load of the server.

[0014] The data resource push method and system provided by this invention utilizes non-interactive zero-knowledge proof technology to implement inter-system authentication, ensuring the authenticity of the identities of all parties involved in the data push process and the security of transactions, while also protecting sensitive information from being leaked. By managing public keys through blockchain technology, it provides tamper-proof records and enhances data security and reliability. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other objects, features, and advantages of the present invention will become more apparent through a more detailed description of the embodiments of the present invention in conjunction with the accompanying drawings. The accompanying drawings are provided to provide a further understanding of the embodiments of the present invention and constitute a part of the specification. Together with the embodiments of the present invention, they are used to explain the present invention and are not intended to limit the present invention. In the drawings, the same reference numerals generally represent the same components or steps.

[0016] Figure 1 It is a flowchart of a data resource pushing method provided by an exemplary embodiment of the present invention.

[0017] Figure 2 It is a structural diagram of a data resource push system provided by an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0018] Below, the exemplary embodiments according to the present invention will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments of the present invention, and it should be understood that the present invention is not limited to the exemplary embodiments described herein.

[0019] Blockchain technology poses a privacy risk during resource push, primarily due to the inherent conflict between its technical characteristics and data transmission mechanisms. For example, the public nature of blockchain ledgers makes all transaction records visible to all nodes in the network. In resource push scenarios, even with anonymous addresses (such as public key hashes), attackers can still conduct correlation analysis through the following methods: by tracking the interaction patterns between resource receiving addresses and known entities (such as exchanges and merchants), combined with off-chain data (such as IP addresses and timestamps), an address-identity mapping relationship can be established. Alternatively, in cross-chain or cross-platform resource push, split / aggregated transaction patterns may reveal user behavior characteristics. For example, if an address regularly receives a specific amount of resources, it may be inferred that it is a salary payment or subscription service.

[0020] Existing technical solutions to address these contradictions have significant limitations. Hybrid encryption obfuscates the flow of funds through an intermediary server, but this relies on a trusted third party, violating the principle of blockchain decentralization. Ring signatures conceal the sender's identity but cannot conceal key information such as the transaction amount. Homomorphic encryption, while enabling computation on encrypted data, suffers from low computational efficiency. More critically, none of these solutions can simultaneously ensure the verifiability of on-chain data while protecting privacy—verifiers must confirm the legitimacy of transactions without accessing sensitive information.

[0021] Therefore, in order to improve privacy protection and reduce the risk of data leakage, this application introduces zero-knowledge proof technology. Zero-knowledge proof allows the prover to prove to the verifier that a statement is true without revealing any additional information.

[0022] Figure 1 FIG. 1 is a flow chart of a data resource push method provided by an exemplary embodiment of the present invention. Figure 1 As shown, first, the public key of the requester is stored in the blockchain system in the form of a key-value pair (see Figure 1 S100). Secondly, when the requester generates a query request, the requester calculates the zero-knowledge proof challenge (see Figure 1 Then, the zero-knowledge proof challenge data and query request parameters are sent to the request recipient (see Figure 1 Finally, when the request receiving party verifies the legitimacy of the requesting party's identity, the requesting party obtains the response data fed back by the request receiving party based on the parameters of the query request (see Figure 1 S400).

[0023] Combined with the following Figure 1 , a more detailed introduction to the data resource push method provided in the embodiment of the present application is given.

[0024] In S100, the public key of the requester is stored in the blockchain system in the form of a key-value pair.

[0025] In some embodiments, the requester may choose to store the private key on its own device, such as a server or other medium. This approach requires the requester to have a high level of security awareness and operational capabilities to ensure the security of the private key.

[0026] In some embodiments, the requester's public key can be hosted in a trusted blockchain system to ensure its security. Based on the requester's server IP address, the requester's public key is stored in the blockchain system as a key-value pair. When a request arrives, the corresponding public key is retrieved through the requester's IP address.

[0027] Blockchain is a distributed, shared ledger and database characterized by decentralization, immutability, full traceability, traceability, collective maintenance, and transparency. Based on the characteristics of blockchain, data information such as the signature verification public key required for data push, the list of push application addresses, the message hash value in a request, the IP addresses of the data requester and recipient, and the hash value of the returned response data are stored in the blockchain system to ensure information security and reliability. A blockchain service network can be deployed based on the blockchain architecture. The blockchain framework can be any blockchain framework that can implement the corresponding functions of the embodiments of this application, such as Bitcoin, Ethereum, Fabric, and Corda.

[0028] Therefore, in order to be more efficient and convenient, in some embodiments, the target address of the requester can also be stored in the blockchain system in the form of a key-value pair; wherein the key-value pair includes the service address number and the specific address of the requesting server; when the requester generates a query request, the service address number is attached as a parameter to the query request, and the requester generates a zero-knowledge proof challenge.

[0029] That is to say, the target address of the requester is stored in the blockchain system in the form of a key-value pair (service address number: specific address of the request server), and a push application address list is maintained, where each service address number corresponds to a specific request server address. The requester attaches the service address number as a parameter in the request and establishes a proxy service as the entry point. In this way, it is only necessary to make a request through the same request address and different parameters, and specifically request to the specified server. The routing function is completed through the proxy service, and the routing function can be completed using reverse proxy components such as Nginx.

[0030] Routing refers to the mechanism by which a proxy server distributes requests to different backend services based on specific rules. When a proxy service is used as an entry point and relies on it to complete the routing function, it usually means that all client requests are first sent to the proxy server, which then forwards the requests to the target backend server based on specific rules (such as load balancing, policy routing, security policies, etc.). When a client requests a proxy service, the user or client (such as a browser or app) does not directly access the target server, but instead sends the request to the proxy server. After receiving the request, the proxy server parses the request content and decides how to forward the request based on the preset routing rules. After the routing decision is made, the proxy server forwards the request to the selected backend server, which processes the request and returns a response to the proxy server.

[0031] In some embodiments, blockchain smart contract functionality can be combined to add a load balancing smart contract that automatically adjusts request routing based on the server's real-time load, ensuring high service availability and optimized performance. A health calibration smart contract can also be added to regularly perform health checks on stored service addresses, promptly identifying and removing unresponsive or slow-responding server addresses to avoid impacting user experience.

[0032] In S200 , when a requester generates a query request, the requester calculates a zero-knowledge proof challenge.

[0033] A zero-knowledge proof (ZKP) is a cryptographic tool that allows two untrusting parties to prove the validity of a proposition without revealing any additional information. A zero-knowledge proof allows the prover to convince the verifier that a statement is correct without providing any useful information to the verifier. It is essentially a protocol involving two or more parties, a set of steps required to complete a task. Zero-knowledge proofs have three key properties: a) Correctness: The prover cannot deceive the verifier. If the prover does not know the proof of a theorem, the probability that they can convince the verifier that they have proved it is very low. b) Completeness: The verifier cannot deceive the prover. If the prover knows the proof of a theorem, they can convince the verifier with a high probability that they have proved it. c) Zero-knowledge: During the entire proof process, the verifier cannot obtain any additional knowledge beyond the fact that the statement is true. Throughout the data resource push process, zero-knowledge proofs primarily serve as authentication between systems. They verify identities through zero-knowledge proofs, then complete the data push and return the results. Blockchain is a distributed, shared ledger or database that stores decentralized and tamper-proof data and information. It uses a distributed database to identify, disseminate, and record information. Combining the characteristics of zero-knowledge proofs and blockchain in the data resource push process can streamline the push process and improve security.

[0034] In order to improve communication efficiency and reduce interaction steps, we convert the interactive zero-knowledge proof into a non-interactive one. In some embodiments, the non-interactive zero-knowledge proof can adopt the following method: the requester generates a trusted random number based on the parameters of the query request and calculates a temporary private key; the requester calculates a challenge value through a preset hash algorithm based on the trusted random number, the public key and the parameters of the query request; the requester calculates a response value based on the challenge value, the temporary private key and the private key; and sends the trusted random number, the response value and the parameters of the query request to the request recipient.

[0035] As a possible implementation, the requester calculates the response value z = r + c × sk based on the challenge value, the temporary private key, and the private key using Formula 1: Formula 1. In Formula 1, z represents the response value. Combining r and sk in response to the challenge c, the requester verifies the proof using z. r represents the temporary private key, a one-time random number that ensures the independence of each proof. c represents the challenge value. The proof is bound to a specific context (pk, R, p) through a hash to prevent pre-computation attacks. sk represents the private key. The requester possesses the private key sk. Using an elliptic curve cryptography algorithm, the public key pk = sk × G is calculated. The public key pk is a public identifier that the requester can use to verify the validity of the proof. G represents the generator base point of the elliptic curve. The requester then generates a trusted random number R based on the query parameter p. Using a selected hash algorithm (such as MD5, SHA-256, or SM3), the hash value c = Hash(pk, R, p) is calculated. The requester then computes a proof z = r + c × sk. R can be generated based on r and submitted as part of the proof, without revealing r by passing z and R. Therefore, R, z, and p are ultimately sent to the requesting recipient.

[0036] For example, R=r×G, r represents a temporary private key, R represents a trusted random number, which is also a temporary public key, G represents the generator base point of the elliptic curve, and R is generated based on r.

[0037] In S300 , the zero-knowledge proof challenge data and query request parameters are sent to the request recipient.

[0038] In some embodiments, the requesting party sends R, z and p to the requesting party. After the requesting party receives R, z and p, the requesting party has the public key pk=sk×G. The requesting party can calculate the challenge value by itself according to the parameters of the query request. The requesting party verifies the validity of the zero-knowledge proof challenge through the requesting party's trusted random number, public key, response value and the challenge value calculated by the requesting party. When the zero-knowledge proof challenge is determined to be valid, the requesting party verifies the legitimacy of the requesting party's identity.

[0039] As a possible implementation, the recipient verifies the validity of the zero-knowledge proof challenge using the requester's trusted random number, public key, response value, and the challenge value calculated by the recipient using Formula 2: z × G = R + c × pk (Formula 2). In Formula 2, z represents the response value, G represents the generator base point of the elliptic curve, R represents the trusted random number, c represents the challenge value calculated by the recipient, and pk represents the requester's public key. pk = sk × G, where sk represents the private key. On the left side, z is directly obtained from the requester's data. On the right side, it is calculated based on R and pk provided by the requester and c calculated by the recipient. When the equation in Formula 2 holds true, meaning both sides are equal, the recipient verifies the requester's identity and the proof is valid. The recipient verifies only from z and R and cannot deduce sk or r, thus achieving zero-knowledge proof validity. Without knowing sk, an attacker cannot generate a valid z that satisfies the verification equation, thus achieving unforgeability. Replacing the interactive challenge with c = Hash(pk, R, p) eliminates the need for two-way communication and achieves non-interactive nature. Therefore, by applying non-interactive zero-knowledge to blockchain and privacy protection protocols, efficient and verifiable privacy protection is achieved.

[0040] In some embodiments, after the requesting party verifies the legitimacy of the requesting party's identity, the data resource push method further includes: performing a digest calculation on the requesting party's original message to generate a first hash value of a fixed length; the requesting party encrypts the first hash value based on a private key to generate a digital signature; the requesting party receives the digital signature and decrypts the digital signature using the requesting party's public key to obtain a first hash value; the requesting party calculates a second hash value; and when the first hash value and the second hash value are the same, it is determined that the original message has not been tampered with. In other words, identity authentication is first performed to ensure that the requesting party is a legitimate entity (possessing sk) to prevent identity forgery, and then the correctness of the data is ensured by signature verification to ensure that the data has not been tampered with during transmission and is sent by an entity with verified identity.

[0041] As a possible implementation, a one-way hash function (such as SHA-256) is used to calculate a digest of the original message, generating a fixed-length hash value. The requester encrypts this hash value with their private key to generate a digital signature. The recipient of the request decrypts the digital signature using the signer's public key to obtain the original hash value, which they then compare with their own recalculated hash value to verify the validity of the signature.

[0042] In S400 , when the request receiving party verifies that the identity of the requesting party is legitimate, the requesting party obtains response data fed back by the request receiving party according to the parameters of the query request.

[0043] After the legal identity is verified, the server of the specific request, the server request address and other information can be filtered out according to the parameters in the request, and the request can be sent to the designated server to receive the response. When the response result is generated, the response data information is returned to the requester. Among them, for requests that are frequently queried and the data does not change much, a response caching mechanism is implemented to reduce unnecessary server access and data transmission. According to the specific needs of the requester, customized response data format and content are provided to improve the availability and flexibility of the data. The customized response function adopts a "pluggable" form. "Pluggable" is an architectural design pattern that allows software modules or components to be dynamically loaded, unloaded or replaced without affecting the operation of the entire system. This enables the entire function to expand or change the customized functions of the system without modifying the core code.

[0044] Figure 2 FIG. 1 is a structural diagram of a data resource push system provided by an exemplary embodiment of the present invention. Figure 2 As shown, the data resource push system 2 includes: a public key management module 21, which is used to store the public key of the requester in the form of a key-value pair in the blockchain system; a non-interactive zero-knowledge proof module 22, which is used for the requester to calculate the zero-knowledge proof challenge when the requester generates a query request; a sending module 23, which is used to send the zero-knowledge proof challenge data and the parameters of the query request to the request recipient; a response processing module 24, which is used for the requester to obtain the response data fed back by the request recipient based on the parameters of the query request when the request recipient verifies the legitimacy of the requester's identity.

[0045] The data resource push system utilizes zero-knowledge proof technology to implement inter-system authentication, ensuring the authenticity of all parties involved in the data push process and the security of transactions, while also protecting sensitive information from being leaked. Blockchain technology stores and manages public keys and other critical information, providing an immutable record and enhancing data security and reliability. Furthermore, the use of non-interactive zero-knowledge proofs reduces the number of communication interactions, improving the efficiency of the data push process. The use of proxy services and load-balancing smart contracts enables efficient request routing, improving service response speed and overall performance. A response caching mechanism reduces unnecessary server access and speeds up responses to frequent queries. Reducing unnecessary server access and data transmission reduces operating costs.

[0046] In some embodiments, the data resource push system further includes: a push application address list management system for storing service address numbers and their corresponding request server addresses; and a routing module for forwarding query requests to a designated server.

[0047] In some embodiments, the data resource push system also includes: a cache module for implementing a response cache mechanism; a customized response module for providing customized response data format and content; and a smart contract module for automatically adjusting request routing according to the real-time load of the server.

[0048] For example, the customized response function adopts a pluggable format, allowing the system to quickly adjust the response content and format according to the needs of different requesters, improving the system's flexibility and adaptability. The application of smart contracts (such as the health calibration smart contract) can automatically remove invalid or inefficient service addresses, ensuring system robustness and service quality. Efficient load balancing strategies and health check mechanisms ensure service stability and high availability, improving the user experience.

[0049] In some embodiments, the non-interactive zero-knowledge proof module 22 may also be configured to: generate a trusted random number based on the query request parameters and calculate a temporary private key; calculate a challenge value using a preset hash algorithm based on the trusted random number, the public key, and the query request parameters; and calculate a response value based on the challenge value, the temporary private key, and the private key. The sending module 23 may be correspondingly configured to send the trusted random number, the response value, and the query request parameters to the request recipient.

[0050] In some embodiments, the non-interactive zero-knowledge proof module 22 can also be configured as: the requesting party calculates the response value based on the challenge value, the temporary private key and the private key through formula 1: z = r + c × sk Formula 1; in formula 1, z represents the response value, r represents the temporary private key, c represents the challenge value, and sk represents the private key.

[0051] In some embodiments, the data resource push system 2 can be configured as follows: the request recipient calculates a challenge value based on the parameters of the query request; the request recipient verifies the validity of the zero-knowledge proof challenge through the requester's trusted random number, public key, response value and the challenge value calculated by the request recipient; when the zero-knowledge proof challenge is determined to be valid, the request recipient verifies the legality of the requester's identity.

[0052] In some embodiments, the data resource push system 2 can also be configured as follows: the request recipient verifies the validity of the zero-knowledge proof challenge through the request recipient's trusted random number, public key, response value and the challenge value calculated by the request recipient through Formula 2: z×G=R+c×pkFormula 2; in Formula 2, z represents the response value, G represents the generator base point of the elliptic curve, R represents the trusted random number, c represents the challenge value calculated by the request recipient, pk represents the public key of the request recipient, pk=sk×G, sk represents the private key; when the equation in Formula 2 is established, the request recipient verifies the legality of the identity of the request recipient.

[0053] In some embodiments, the data resource push system 2 may be further configured to store the requester's target address in the blockchain system via a key-value pair, wherein the key-value pair includes a service address number and the specific address of the requesting server. Furthermore, the non-interactive zero-knowledge proof module 22 may be further configured to include the service address number as a parameter in a query request when the requester generates the query request, thereby generating a zero-knowledge proof challenge.

[0054] In some embodiments, the data resource push system 2 can also be configured to: perform a digest calculation on the original message of the requester to generate a first hash value of a fixed length; the requester encrypts the first hash value based on a private key to generate a digital signature; the requesting party receives the digital signature and decrypts the digital signature using the public key of the requester to obtain the first hash value; the requesting party calculates a second hash value; when the first hash value is the same as the second hash value, it is determined that the original message has not been tampered with.

[0055] An embodiment of the present invention provides a data resource push device. The device embodiment can be implemented through software, hardware, or a combination of software and hardware. From a hardware perspective, in addition to the CPU, memory, network interface, and non-volatile memory, the device in the embodiment may also generally include other hardware, such as a forwarding chip responsible for processing messages, etc. Taking software implementation as an example, as a device in a logical sense, it is formed by the CPU of the device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them.

[0056] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the storage medium stores a computer program, and the computer program is used to execute the data resource pushing method of any of the above embodiments.

[0057] In addition to the above methods and devices, embodiments of the present invention may also be computer program products, which include computer program instructions. When the computer program instructions are executed by a processor, the processor executes the steps of the data resource push method according to various embodiments of the present invention described above.

[0058] According to another aspect of the present invention, an electronic device is provided, comprising: a processor; a memory for storing instructions executable by the processor; and the processor for executing the data resource pushing method of any of the above embodiments.

[0059] In addition, an embodiment of the present invention may also be a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are executed by a processor, the processor executes the steps of the data resource pushing method according to various embodiments of the present invention described above.

[0060] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A data resource push method, characterized in that: Data resource push methods include: The public key of the requester is stored in the blockchain system in the form of a key-value pair; When the requester generates a query request, the requester calculates the zero-knowledge proof challenge; Sending the zero-knowledge proof challenge data and query request parameters to the request recipient; When the request receiver verifies that the identity of the requester is legitimate, the requester obtains response data fed back by the request receiver according to the parameters of the query request.

2. The data resource push method according to claim 1, characterized in that: When the requester generates a query request, the requester calculates the zero-knowledge proof challenge, including: The requester generates a trusted random number based on the query request parameters and calculates a temporary private key; The requester calculates the challenge value using a preset hash algorithm based on the trusted random number, public key, and query request parameters. The requester calculates a response value based on the challenge value, the temporary private key, and the private key; The step of sending the zero-knowledge proof challenge data and query request parameters to the request recipient includes: The trusted random number, the response value and the query request parameters are sent to the request recipient.

3. The data resource push method according to claim 2, characterized in that: The requester calculates a response value based on the challenge value, the temporary private key, and the private key, including: The requester calculates the response value according to the challenge value, temporary private key and private key using Formula 1: z=r+c×sk Formula 1; In Formula 1, z represents the response value, r represents the temporary private key, c represents the challenge value, and sk represents the private key.

4. The data resource push method according to claim 2, characterized in that: When the request receiving party verifies the legality of the identity of the requesting party, before the requesting party obtains the response data fed back by the request receiving party according to the parameters of the query request, the data resource pushing method further includes: The request receiver calculates a challenge value according to the parameters of the query request; The request receiving party verifies the validity of the zero-knowledge proof challenge by using the trusted random number of the requesting party, the public key, the response value, and the challenge value calculated by the request receiving party; When the zero-knowledge proof challenge is determined to be valid, the request recipient verifies the legitimacy of the requester's identity.

5. The data resource pushing method according to claim 4, characterized in that: The request receiving party verifies the validity of the zero-knowledge proof challenge using the trusted random number of the requesting party, the public key, the response value, and the challenge value calculated by the request receiving party, including: The request recipient verifies the validity of the zero-knowledge proof challenge using Formula 2 using the trusted random number of the requester, the public key, the response value, and the challenge value calculated by the request recipient: z×G=R+c×pk Formula 2; In Formula 2, z represents the response value, G represents the generator base point of the elliptic curve, R represents a trusted random number, c represents the challenge value calculated by the request recipient, pk represents the public key of the requester, pk = sk × G, and sk represents the private key; When the zero-knowledge proof challenge is determined to be valid, the request recipient verifies the legitimacy of the requesting party, including: When the equation in Formula 2 holds true, the request receiver verifies that the identity of the requester is legitimate.

6. The data resource pushing method according to claim 1, characterized in that: Also includes: The target address of the requesting party is stored in the blockchain system in the form of a key-value pair; wherein the key-value pair includes the service address number and the specific address of the requesting server; When the requester generates a query request, the requester generates a zero-knowledge proof challenge, including: When the requesting party generates a query request, the service address number is attached as a parameter in the query request, and the requesting party generates a zero-knowledge proof challenge.

7. The data resource pushing method according to claim 1, characterized in that: After the request recipient verifies the identity of the requester is legitimate, the data resource push method further includes: Performing a digest calculation on the original message of the requesting party to generate a first hash value of a fixed length; The requesting party encrypts the first hash value based on a private key to generate a digital signature; The request recipient receives the digital signature and decrypts the digital signature using the public key of the requester to obtain the first hash value; The request recipient calculates a second hash value; When the first hash value is identical to the second hash value, it is determined that the original message has not been tampered with.

8. A data resource push system, characterized in that: The data resource push method according to any one of claims 1 to 7 above, wherein the data resource push system comprises: A public key management module, which is used to store the requester's public key in the form of a key-value pair in the blockchain system; A non-interactive zero-knowledge proof module, wherein the non-interactive zero-knowledge proof module is used for the requesting party to calculate a zero-knowledge proof challenge when the requesting party generates a query request; A sending module, configured to send the zero-knowledge proof challenge data and query request parameters to a request recipient; The response processing module is used for, when the request receiving party verifies the legality of the identity of the requesting party, for the requesting party to obtain the response data fed back by the request receiving party according to the parameters of the query request.

9. The data resource push system according to claim 8, characterized in that: Also includes: Push application address list management system, which is used to store service address numbers and their corresponding request server addresses; The routing module is used to forward the query request to the designated server.

10. The data resource push system according to claim 8, characterized in that: Also includes: Cache module, used to implement response caching mechanism; Customized response module, used to provide customized response data format and content; A smart contract module that automatically adjusts request routing based on the server's real-time load.

Images