Internet basic resource-oriented data exchange method and system

Abstract

The invention discloses a data exchange method and system for internet basic resources, and relates to the technical field of network space security and data exchange. According to the technical key points, the initial state, a data publisher and a data receiver of the data exchange system are defined, verification is carried out by adopting a joint signature verification mechanism based on SMPC or a node signature-by-signature verification mechanism, and the joint signature verification mechanism based on SMPC takes the data publisher as the center; all nodes within the trust range of the publisher can be used as verifiers, and the publisher can adjust the trust set according to a verification result; the node signature-by-signature verification mechanism takes a data receiver as a center, if verification is passed, the content is proved to be consistent, and the node is written into a consistency verification list; and after verification is completed, the data receiver verifies the consistency verification list according to a self-defined verification condition and feeds back a result to the publisher. The method has better practicability and expandability, verification conditions can be flexibly configured to adjust a fault-tolerant threshold value, and the limitation of a traditional fixed proportion is broken through. According to the invention, the throughput can meet the performance requirement of an actual service scene, and the super-large-scale network deployment capability is realized.

Description

Technical Field

[0001] The present invention relates to the field of cyberspace security and data exchange technology, and in particular to a data exchange method and system for Internet basic resources. Background Art

[0002] Internet infrastructure, as the core elements supporting the operation of the internet, primarily includes three key resources: domain names, numbers, and certificates. The current governance system for these resources is highly centralized, posing serious security risks. Regarding domain names, the global domain name system utilizes a hierarchical management architecture. ICANN controls the approval of root zone data, while VeriSign, a US company, provides technical maintenance through 13 logical root servers and their global mirror nodes. Regarding number resources, the allocation of IP addresses and autonomous domain numbers is centralized in the five Regional Internet Registries (RIRs). While RPKI technology provides an authentication mechanism for BGP routes, it has yet to be fully deployed. The certificate system is dominated by commercial CAs, with US-based CAs holding 80% of the global market share.

[0003] This centralized governance structure leads to three types of security risks: 1) The risk of network isolation caused by infrastructure service interruption. When overseas root servers, RIR repositories or CA agencies stop providing services, the resolution of related resources will become invalid; 2) The risk of disappearance caused by the revocation of national-level resources. Once key resource data is deleted, the corresponding network services will be inaccessible globally; 3) The risk of hijacking caused by the tampering of important resources. Malicious modification of domain names, IP addresses or certificate data will cause services to be illegally hijacked.

[0004] The industry has proposed a variety of solutions to these problems, but all have significant limitations. While blockchain naming systems (such as Namecoin, ENS, and BNS) achieve decentralized management, they independently issue a new domain name system outside the IANA root zone, rendering traditional DNS resolution inoperable. Alternative root system solutions (such as Project Snowman and Russia's Runet) also struggle to ensure global namespace consistency. Transparent audit mechanisms (such as RPKI Transparency and Certificate Transparency Logs) only provide post-mortem detection capabilities. Distributed Infrastructure (DII) addresses the issues of central node authority and data monopoly through consensus algorithms and distributed ledger technology, but in practice, it still faces challenges such as insufficient privacy protection and poor compatibility with existing systems. Furthermore, detailed performance evaluation and feasibility analysis are lacking. Of particular note, the security of my country's internet infrastructure is particularly severe: a large number of important system domain names are registered overseas, CA certificates rely heavily on foreign institutions for issuance, and numbering resources are governed by APNIC. This poses a greater risk to my country's cyberspace security.

[0005] Against this backdrop, there is an urgent need to build a technology system for safeguarding ownership of internet infrastructure resources that is compatible with existing systems and autonomous and controllable. This system must integrate key technologies such as distributed consensus verification, efficient data exchange algorithms, and secure multi-party computing to effectively address the increasingly severe security challenges facing the current internet infrastructure sector. Summary of the Invention

[0006] The technical problems to be solved by the present invention are:

[0007] The present invention aims to address the problem that existing data exchange methods fail to integrate key technologies such as distributed consensus verification, efficient data exchange algorithms, and secure multi-party computing, and are unable to effectively address the increasingly severe security challenges in the field of Internet infrastructure resources. To this end, the present invention provides a data exchange method and system for Internet infrastructure resources.

[0008] The technical solution adopted by the present invention to solve the above technical problems is: a data exchange system for Internet basic resources described in the present invention is specifically:

[0009] The initial state of the data exchange system is defined as:

[0010] Each node in the system configures a communication member set (the set of other nodes known to the node within global access) and a trusted member set (nodes that the node believes will not collude to deceive it), generates a key pair locally, and obtains the public keys of the communication members. Administrators configure custom verification conditions, gossip cycles, and anti-entropy synchronization cycles based on actual application requirements.

[0011] Each node periodically propagates Gossip metadata, randomly selects k nodes from the communication member set, and sends its own known resource data list; at the same time, each node randomly selects a node from the trusted member set according to the configured anti-entropy synchronization period to exchange the complete known resource data list, obtain relevant resource data, and repair the differences;

[0012] The data publisher of the data exchange system is defined as:

[0013] The data publisher generates the corresponding resource data, adds a digital signature to it, and publishes it to the local server along with the original data, allowing any node in the system to access and download it. The publisher needs to update the version number of the published data based on historical release information. The version number includes a date and a number. The resource data is named by the data identifier and version number and is unique globally. A timer is set to wait for other nodes to receive the data.

[0014] After the timer expires, the data publisher obtains the feedback notification from the message queue and verifies its signature; the nodes that pass the verification are written into the "receiving list", which contains the node identification information, IP address and its digital signature; in this process, the publisher only needs to confirm the credibility of the notification source, without having to compare the consistency of the data disclosed by the recipient with the original data; this process is used to evaluate the scope of data dissemination and determine whether it meets the "sufficient disclosure" standard based on the set custom verification conditions; if the receiving list meets the verification conditions, the publisher adds a digital signature to it and publishes it on the local server; otherwise, the verification failure result is fed back to the corresponding node in the receiving list; set a timer and wait for other nodes to verify the receiving list.

[0015] After the timer expires, the data publisher verifies the consistency verification results one by one based on the feedback from each receiver, and writes the node information that has passed the verification into the "public list". It then determines whether the public list meets the public conditions based on the preset custom verification conditions. If the conditions are met, it can be considered that the data has been widely disseminated and the trust members have received the correct data.

[0016] The data receiver of the data exchange system is defined as:

[0017] The node compares the received metadata content with the local version. If missing data is found, the receiver needs to verify whether the data source is a trusted member and whether the version number of the data is higher than the local version. If the verification is successful, the node obtains the missing data and its signature from the data publisher and updates the local Gossip metadata. During the data reception process, the node needs to verify whether the data publisher is in the pre-configured trust set and compare it with the locally stored version number to determine whether it is an updated version. If new data is found to be released, the node obtains the data and its signature and verifies the signature. If the verification is successful, the data is digitally signed and published on the server, otherwise it is written to the exception log. Finally, the node actively pushes the data reception status to the publisher and sets a timer.

[0018] After the timer expires, the data receiver obtains the receiving list from the publisher and verifies the signature list in it. This process is used to verify the consistency of data received and serves as a criterion for determining whether the data is "sufficiently consistent";

[0019] Verification is performed using a joint signature verification mechanism based on SMPC or a node-by-node signature verification mechanism. The SMPC-based joint signature verification mechanism is centered on the data publisher, and all nodes within the publisher's trust range can serve as verifiers. The publisher can adjust the trust set based on the verification results; the node-by-node signature verification mechanism is centered on the data receiver. If the verification passes, it proves that the content is consistent, and the node is written into the "consistency verification list." After the verification is completed, the data receiver verifies the consistency verification list according to the custom verification conditions and feeds back the results to the publisher.

[0020] Furthermore, the data exchange system is also constructed with a digital signature management module that is simple in structure, safe, reliable and readable. The digital signature management module is designed with a self-configured signature set:

[0021] On the one hand, in the data exchange scenario, each data exchange process is regarded as an independent transaction. Since each transaction is independent of each other, the self-configured signature set stores the signature information of a single transaction in one file for centralized signature. The signature sets of different transactions do not need to be connected to each other, which simplifies the data structure. On the other hand, the self-configured signature set only retains the necessary node information and its corresponding signature data in the content record, and optimizes the record format to improve readability, making it easier for users to identify and track abnormal nodes, and digitally sign the signature set file as a whole.

[0022] Furthermore, during the verification process, the data exchange system is designed with a joint signature verification mechanism based on secure multi-party computing (SMPC) and a node-by-node signature verification mechanism to meet different application requirements, in order to balance the security and flexibility of the overall algorithm. Specifically:

[0023] The SMPC-based joint signature verification mechanism aims to achieve decentralization and prevent Byzantine nodes from doing evil. The verification process mainly includes the following two steps:

[0024] 1) For each node signature record in the signature set, based on the threshold secret sharing mechanism (such as Shamir SecretSharing), the node's public key information Q, signature (r, s) and message digest H(data) are split into several secret fragments and distributed to pre-selected verification nodes respectively;

[0025] 2) Each verification node jointly executes a signature verification function based on a multi-party secure computation protocol (such as ECDSA under MPC) without revealing the contents of the secret fragments it holds. This function does not expose intermediate data during the calculation process and only outputs a Boolean value to determine whether the signature is valid. The verification process adopts a (k,n) threshold strategy, where n represents the total number of nodes participating in the verification and k is the minimum number of nodes required to complete the verification, thereby achieving Byzantine fault tolerance and decentralization of the verification process.

[0026] The node-by-node signature verification mechanism is designed to adapt to the needs of different business scenarios. That is, each signature can be verified sequentially in a local or trusted environment, and its validity is judged based on a configurable minimum number of valid signatures. It is suitable for fast verification of signature sets in scenarios where computing resources are scarce or distributed computing is not required.

[0027] Furthermore, the data exchange system is also designed with a multi-copy verification mechanism, which is used as the basis for determining whether data is successfully released. According to the requirements of different scenarios, two verification mechanisms are provided: quantity threshold verification and specific node verification. The nodes can flexibly configure the verification method according to actual needs.

[0028] Furthermore, the quantity threshold verification mechanism relies on counting the number of nodes that receive data. During the Gossip-based data exchange algorithm, from the dissemination range verification phase (Phase 3) to the "sufficiently public" and "sufficiently consistent" verification phase (Phase 5), nodes must set different trust set membership ratios as verification strategies at each stage, denoted as t3, t4, and t5, respectively. In this algorithm, the data publisher and its mutually trusted member set are defined as a "federation." Because the trust set is autonomously configured by nodes and is not subject to any centralized constraints, different federations can be independent and non-intersecting.

[0029] Furthermore, the specific implementation process of the quantity threshold verification mechanism for a single federation is as follows: Assume that a federation consists of n nodes that trust each other with the data publisher, and there is a lack of mutual trust between these n nodes; in this case, the publisher's trust set should include n nodes, and the trust sets of other nodes should include nm (0≤m <n)个节点;

[0030] We analyze two scenarios. First, we consider the case where there are f Byzantine nodes in the system. These Byzantine nodes may maliciously tamper with the data content or send back false notifications. The Byzantine fault tolerance standard is defined as follows: 1) If a normal node passes verification in the consistency verification phase, then the data should be considered sufficiently public and sufficiently consistent; 2) If a normal node fails verification in this phase, the data is invalidated to ensure the correctness of the algorithm. In this case, the number of nodes in different lists can be expressed as follows:

[0031] Number of nodes in the consistency verification list = nf-1#(1)

[0032]

[0033] We analyze the worst-case scenario, where all Byzantine nodes attempt to tamper with the data and send false notifications to the publisher before the consistency verification phase ends. During the propagation range verification phase, if the receiving list passes verification, the algorithm proceeds to the next phase; otherwise, the publisher proactively terminates the algorithm. Since the verification results of this phase do not affect the correctness of the algorithm, the number of nodes in the receiving list is not calculated.

[0034] In the worst-case scenario, all receivers report that they have obtained and published the data, resulting in n nodes in the receiving list and nf-1 nodes in the consistency verification list. If the non-Byzantine nodes pass the consistency verification phase, all Byzantine nodes attempt to report verification failures to prevent the data from being published. In this case, nf nodes are listed as public. Conversely, if the Byzantine nodes report verification success, f nodes are listed as public. To ensure the correctness of the algorithm, the following constraints must be met when the consistency verification phase passes:

[0035]

[0036] If a node fails verification during the consistency verification phase, the following conditions must be met:

[0037]

[0038] In the above analysis, formula (3) ensures that non-Byzantine nodes can pass verification during the consistency verification phase. If verification is passed, then the Byzantine nodes will not affect the algorithm execution results; formula (4) ensures that the final data release results will not be incorrect due to the excessive number of Byzantine nodes. In summary, under the premise of ensuring the correctness of the algorithm, the maximum number of Byzantine nodes that a federation consisting of N = n + 1 nodes can tolerate can be expressed as:

[0039]

[0040] Consider the situation where there are d nodes down in the system. At this time, the lists of normal nodes should satisfy:

[0041] Number of nodes in the receiving list = nd#(6)

[0042]

[0043]

[0044] Because down nodes cannot receive data or feedback messages, the number of nodes in the receiving list is nd, and the number of nodes in the consistency verification list is nd-1. If all normal nodes pass the consistency verification, the number of nodes in the public list is nd, otherwise it is empty. To ensure that data passes the verification successfully, the following conditions must be met:

[0045]

[0046]

[0047]

[0048] Based on the above analysis, in a federation consisting of N = n + 1 nodes, the maximum number of down nodes allowed to ensure successful data disclosure cannot exceed:

[0049]

[0050] Specific node verification relies on the selection and evaluation of specific nodes. During the verification process, the verification result is considered valid only when all selected nodes pass the verification. Each node selects several nodes with the highest trust level as a specific verification set based on the trust set.

[0051] Furthermore, a specific node verification mechanism is used to improve the accuracy of the verification process. If the verification passes, all nodes in the verification set will receive consistent data. This mechanism is used to further screen a smaller set of nodes based on the trust set, reducing the impact of Byzantine nodes on the verification results.

[0052] A data exchange system method for Internet basic resources includes steps corresponding to the program modules of the above-mentioned data exchange system for Internet basic resources.

[0053] A computer-readable storage medium stores a computer program, wherein the computer program is configured to implement the steps of a data exchange system method for Internet basic resources when called by a processor.

[0054] The present invention has the following beneficial technical effects:

[0055] The Gossip-based data exchange algorithm proposed in this paper has significant improvements over the existing technologies (PBFT / Ripple). The specific comparison is as follows:

[0056] Time complexity: The time complexity of the existing PBFT algorithm is O(N 2), while the Ripple algorithm is O(M), the proposed gossip-based data exchange algorithm has an optimized time complexity of O(M) + a dynamic trust mechanism. In PBFT applications, this solution can significantly reduce communication traffic by 99%. Compared to the Ripple protocol, the dynamic trust mechanism addresses the difficulty of flexibly establishing mutual trust between members in real-world scenarios, offering greater practicality and scalability.

[0057] Byzantine fault tolerance: This invention innovatively proposes a dynamic fault tolerance model that can flexibly configure verification conditions and adjust the fault tolerance threshold, breaking through the limitations of traditional fixed ratios.

[0058] System throughput: In a data publishing test of 30,000 records, this solution achieved a throughput of 200 TPS, meeting the performance requirements of actual business scenarios.

[0059] Large-scale node deployment: Existing technologies cannot effectively publish data at a scale of 1,000 nodes. However, this solution leverages the advantages of the Gossip protocol to complete data publishing within 30 minutes, enabling ultra-large-scale network deployment capabilities.

[0060] Therefore, this invention effectively addresses the problems of the aforementioned existing technologies by providing data exchange technology for internet infrastructure resources, building a self-sustainable and controllable technology system for protecting ownership of internet infrastructure resources that is compatible with existing systems. This system integrates key technologies such as distributed consensus verification, efficient data exchange algorithms, and secure multi-party computation, effectively addressing the increasingly severe security challenges in the field of internet infrastructure resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0061] Figure 1 A flowchart of the algorithm on which the present invention is based; Figure 2 This is a logical structure diagram of the algorithm of the present invention; Figure 3 The throughput graph is for different data sizes; Figure 4 This is a comparison chart of overall delay under different network scales; Figure 5 This is a comparison chart of delays at each stage under different network scales; Figure 6 Test graphs for large-scale deployment; Figure 7 The resource consumption graph under different numbers of concurrent transactions. DETAILED DESCRIPTION

[0062] Combined with attachment Figures 1 to 7 , the implementation of a data exchange method and system for Internet basic resources according to the present invention is described as follows:

[0063] 1. For the Gossip-based data exchange algorithm proposed in the present invention, the following pseudo code is given for understanding the present invention (based on the underlying code of the software developed in the present invention):

[0064] 1) Data Structure

[0065] ① Resource data

[0066]

[0067]

[0068] ②Gossip metadata

[0069]

[0070] 2) Algorithm Process

[0071] Initial state

[0072] Each node in the system configures its communication membership (the set of other nodes known to it within the global access scope) and trusted membership (nodes it trusts will not collude to deceive it), generates a key pair locally, and obtains the public keys of the communication members. Administrators configure custom verification conditions, gossip cycles, and anti-entropy synchronization cycles based on actual application requirements.

[0073] Each node periodically broadcasts gossip metadata, randomly selects k nodes from the communication member set, and sends its own list of known resource data. At the same time, each node randomly selects a node from the trusted member set according to the configured anti-entropy synchronization period to exchange the complete list of known resource data, obtain relevant resource data, and repair the differences.

[0074] Data publisher

[0075] The data publisher generates the corresponding resource data, digitally signs it, and publishes it along with the original data on a local server, allowing any node in the system to access and download it. The publisher needs to update the version number of the data to be published based on historical release information. The version number consists of a date and a number, such as "20250419T01." If new data with the same identifier is released on the same day, the number after the letter T is incremented by 1. Resource data is named by the data identifier and version number and is unique globally. Finally, a timer is set to wait for other nodes to receive the data.

[0076] After the timer expires, the data publisher gets the notification of feedback from the message queue and verifies its signature. The nodes that pass the verification are written into the "receiving list", which contains the node identification information, IP address and its digital signature. In this process, the publisher only needs to confirm the credibility of the source of the notification, without comparing the consistency of the data disclosed by the receiver with the original data. The core purpose of this process is to evaluate the spread of the data and determine whether it meets the "sufficiently public" standard based on the set custom verification conditions. If the receiving list meets the verification conditions, the publisher adds a digital signature to it and publishes it on the local server; otherwise, the result of the failed verification is fed back to the corresponding node in the receiving list. Finally, the timer is set and the other nodes are waiting for the verification of the receiving list.

[0077] After the timer expires, the data publisher gets the notification of feedback from the message queue and verifies its signature. The nodes that pass the verification are written into the "receiving list", which contains the node identification information, IP address and its digital signature. In this process, the publisher only needs to confirm the credibility of the source of the notification, without comparing the consistency of the data disclosed by the receiver with the original data. The core purpose of this process is to evaluate the spread of the data and determine whether it meets the "sufficiently public" standard based on the set custom verification conditions. If the receiving list meets the verification conditions, the publisher adds a digital signature to it and publishes it on the local server; otherwise, the result of the failed verification is fed back to the corresponding node in the receiving list. Finally, the timer is set and the other nodes are waiting for the verification of the receiving list.

[0078] Data receiver

[0079] The node compares the received metadata content with the local data. If it finds missing data, the receiver needs to verify whether the data source is a trusted member and whether the version number of the data is higher than the local version. If the verification is passed, the node gets the missing data and its signature from the data publisher and updates the local Gossip metadata. During the data receiving process, the node needs to verify whether the data publisher is in the pre-configured trust set and compare the version number with the locally stored version to determine whether it is an updated version. If new data is found to be published, the node gets the data and its signature and verifies the signature. If the verification is passed, the node adds a digital signature to the data and publishes it on the server, otherwise it writes an exception log. Finally, the node actively pushes the data receiving situation to the publisher and sets the timer.

[0080] After the timer expires, the data recipient obtains the recipient list from the publisher and verifies the signature list within it. The purpose of this process is to verify the consistency of the data received, serving as a criterion for determining whether the data is "sufficiently consistent." This can be achieved by employing either a joint signature verification mechanism based on SMPC or a node-by-node signature verification mechanism. The SMPC-based joint signature verification mechanism is centered on the data publisher, and all nodes within the publisher's trust range can serve as verifiers. The publisher can adjust the trust set based on the verification results. The node-by-node signature verification mechanism is centered on the data recipient, offering a simple and fast verification process. If verification passes, it proves the content is consistent, and the node is added to the "consistency verification list." After verification is complete, the data recipient verifies the consistency verification list according to custom verification conditions and provides feedback to the publisher.

[0081] Self-configured signature set

[0082] This technical solution designs a self-configuring signature set, aiming to establish a digital signature management method with a simple structure, security, reliability, and strong readability. Its core design concepts are mainly reflected in two aspects: First, in the data exchange scenario, we regard each data exchange process as an independent transaction. Since each transaction is independent of each other, the self-configuring signature set stores the signature information of a single transaction in a single file, avoiding the problem of low verification efficiency caused by signatures being scattered across multiple blocks in traditional blockchains. In addition, the signature sets of different transactions do not need to be interconnected, further simplifying the data structure. On the other hand, the self-configuring signature set simplifies the content recording, retaining only the necessary node information and its corresponding signature data, and optimizes the record format to improve readability, making it easier for users to identify and track abnormal nodes. To ensure security, the system digitally signs the signature set file as a whole.

[0083] During the verification process, a joint signature verification mechanism based on secure multi-party computing (SMPC) and a node-by-node signature verification mechanism were designed to meet different application requirements, taking into account the overall security and flexibility of the algorithm.

[0084] The SMPC-based joint signature verification mechanism aims to achieve decentralization and prevent Byzantine nodes from acting maliciously. The verification process mainly includes the following two steps:

[0085] 1) For each node signature record in the signature set, the system divides the node's public key information Q, signature (r, s) and message digest H(data) into several secret fragments based on the threshold secret sharing mechanism (such as ShamirSecret Sharing), and distributes them to pre-selected verification nodes respectively.

[0086] 2) Each verification node jointly executes the signature verification function based on a multi-party secure computing protocol (such as ECDSA under MPC) without revealing the contents of the secret fragments it holds. This function does not expose intermediate data during the calculation process and only outputs a Boolean value result to determine whether the signature is legal. The verification process adopts a (k,n) threshold strategy, where n represents the total number of nodes participating in the verification and k is the minimum number of nodes required to complete the verification, thereby achieving Byzantine fault tolerance and decentralization of the verification process. To meet the needs of different business scenarios, the system also supports a node-by-signature verification mechanism, that is, each signature can be verified in sequence locally or in a trusted environment, and its validity is judged based on a configurable minimum number of valid signatures. This verification mode is suitable for rapid verification of signature sets in scenarios where computing resources are scarce or distributed computing is not required. It has the advantages of low implementation cost and flexible deployment.

[0087] Multi-copy verification mechanism

[0088] This technical solution incorporates Byzantine Fault Tolerance (BFT) principles to design a multi-copy verification mechanism, intended to serve as the basis for determining successful data release. Two verification mechanisms, quantity threshold verification and specific node verification, are proposed to meet the needs of different scenarios. Nodes can flexibly configure verification methods based on actual needs.

[0089] The quantity threshold verification mechanism relies on counting the number of nodes that receive data. During the operation of the gossip-based data exchange algorithm, from the dissemination range verification phase (phase 3) to the "sufficiently public" and "sufficiently consistent" verification phase (phase 5), nodes must set different trust set member ratios as verification strategies at each phase, denoted as t3, t4, and t5, respectively. In this algorithm, we define the data publisher and its mutually trusted member set as a "federation." Because the trust set is configured autonomously by nodes and is not subject to any centralized constraints, different federations may be independent and have no intersection. Therefore, the following analysis focuses on a single federation.

[0090] In general, assume that a federation consists of n nodes that trust the data publisher, but there is a lack of mutual trust between these n nodes. In this case, the publisher's trust set should include n nodes, and the trust sets of other nodes should include nm (0≤m <n)个节点。

[0091] Two cases are analyzed. First, consider the case where there are f Byzantine nodes in the system, which can maliciously tamper with data content or send false notifications. The Byzantine fault tolerance criteria defined are as follows: 1) If a normal node passes the verification in the consistency verification phase, the data should be considered sufficiently public and consistent. 2) If a normal node fails the verification in the phase, the data is discarded to ensure the correctness of the algorithm. In this case, the number of nodes in the consistency verification list can be represented as follows:

[0092] Number of nodes in consistency verification list = n-f-1#(1)

[0093]

[0094] Only the worst case is analyzed, that is, all Byzantine nodes try to tamper with the data and send false notifications to the publisher before the consistency verification phase ends. In the propagation range verification phase, if the received list verification passes, the algorithm will enter the next phase; otherwise, the publisher actively terminates the algorithm. Since the verification result of this phase does not affect the correctness of the algorithm, the number of nodes in the received list is not calculated.

[0095] In the worst case, all recipients feedback the notification that the data has been obtained and published, so the number of nodes in the received list is n, and the number of nodes in the consistency verification list is n-f-1. If the non-Byzantine node passes the verification in the consistency verification phase, all Byzantine nodes try to feedback the notification of verification failure to prevent the data from being published, so the number of nodes in the published list is n-f; otherwise, the Byzantine node feedbacks the verification pass, so the number of nodes in the published list is f. To ensure the correctness of the algorithm, the following constraint condition needs to be met when the consistency verification phase passes:

[0096]

[0097] If the node fails the verification in the consistency verification phase, the following conditions need to be met:

[0098]

[0099] In the above analysis, formula (3) ensures that non-Byzantine nodes can pass the verification in the consistency verification phase. If the verification passes, the Byzantine node will not affect the execution result of the algorithm. Formula (4) ensures that the final publication result of the data will not be wrong due to too many Byzantine nodes. In summary, under the premise of ensuring the correctness of the algorithm, the maximum number of Byzantine nodes that can be tolerated by the federation composed of N = n+1 nodes can be represented as:

[0100]

[0101] Further considering the case that there are d nodes down in the system, at this time, each list of the normal nodes should satisfy:

[0102] The number of nodes in the receiving list = n-d# (6)

[0103]

[0104]

[0105] Since the down nodes cannot receive data or feedback messages, the number of nodes in the receiving list is n-d, and the number of nodes in the consistency verification list is n-d-1. If all normal nodes pass the consistency verification, the number of nodes in the disclosure list is n-d, otherwise it is empty. In order to ensure that the data passes the verification successfully, the following conditions need to be met:

[0106]

[0107]

[0108]

[0109] Based on the above analysis, in a federation consisting of N = n+1 nodes, the maximum number of allowed down nodes to ensure successful data disclosure cannot exceed:

[0110]

[0111] The specific node verification depends on the selection and evaluation of specific nodes, and the core idea is that in the verification process, only when all selected nodes pass the verification, the verification result is considered valid. Specifically, each node selects a number of nodes with the highest trust degree from the trust set as the specific verification set. Compared with the quantity threshold verification, this mechanism pays more attention to the trust relationship and recognition degree between nodes. This mechanism is usually combined with the quantity threshold verification mechanism to provide more flexible verification strategy configuration for nodes to adapt to different application scenarios.

[0112] Compared with the quantity threshold verification mechanism, the advantages of the specific node verification mechanism mainly lie in two aspects: on the one hand, it can improve the accuracy of the verification process. If it passes the verification, all nodes in the verification set must have received consistent data; on the other hand, this mechanism further filters a smaller range of node set based on the trust set, effectively reducing the influence of the Byzantine node on the verification result.

[0113] The Gossip-based data exchange algorithm proposed in the application has obvious progress compared with the prior art (PBFT / Ripple).

[0114] The specific comparison is as follows:

[0115] 1. Time complexity: The time complexity of the existing PBFT algorithm is O(N 2 ), the time complexity of the Ripple algorithm is O(M), and the time complexity of the Gossip-based data exchange algorithm proposed by the application is optimized to O(M) + dynamic trust mechanism. In the PBFT application scenario, the present scheme can realize a significant effect of reducing the communication volume by 99%.

[0116] Compared with the Ripple protocol, the dynamic trust mechanism can cope with the problem that mutual trust between members in a real scenario is difficult to flexibly establish, and has better practicability and scalability.

[0117] 2. Byzantine fault tolerance: The fault tolerance upper limit of the PBFT in the prior art is (N-1) / 3, and the fault tolerance upper limit of the Ripple is (N-1) / 5. The application innovatively proposes a dynamic fault tolerance model The verification condition can be flexibly configured to adjust the fault tolerance threshold, thereby breaking through the limitation of the traditional fixed proportion.

[0118] 3. System throughput: In a data publishing test of 30000 records, the present scheme realizes a throughput of 200TPS, which meets the performance requirements of the actual business scenario.

[0119] 4. Large-scale node deployment: The prior art cannot realize effective data publishing under the condition of 1000 nodes, while the present scheme can complete data publishing within 30 minutes by using the advantages of the Gossip protocol, and has the ability of super-large-scale network deployment.

[0120] Table 1 Algorithm comparison

[0121]

[0122] The present application makes systematic improvements on the technical defects existing in the domain name, code number and certificate resource management field in the prior art, and the specific comparative analysis is as follows:

[0123] 1. Blockchain naming system (such as Namecoin, ENS, BNS, etc.): The prior art constructs an independent domain name system outside the IANA root area, which causes the traditional DNS system to be unable to parse. The present application uses the traditional IANA resource data under the premise of multi-party governance decentralization, is compatible with the traditional DNS system, and solves the above problems.

[0124] 2. Alternative root system scheme (such as the Snowman plan, Runet): The regional root server scheme cannot guarantee the consistency of global domain name resolution due to different name space management strategies. The present application proposes a globally compatible decentralized resource management scheme, which realizes real-time consistency maintenance of data through multi-party data exchange, data merging, anti-entropy synchronization and other mechanisms.

[0125] 3. Transparency audit mechanism (such as RPKI Transparency, Certificate Transparency Log, etc.): Traditional audit techniques rely on post-log analysis, and malicious operations on centralized agencies can only achieve lag detection. The present application introduces a multi-copy verification mechanism, which performs consistency verification of multi-party data during the resource exchange stage, achieving pre-prevention of malicious nodes.

[0126] 4. Distributed infrastructure (such as DII): Although decentralization is achieved at the resource allocation layer, the rule-making layer and identity authentication layer still cannot escape the centralized structure, which is more suitable for resisting root tampering and certificate forgery, but powerless against the failure of the authoritative server itself. And it does not provide a perfect compatibility design scheme and system performance evaluation. The present application can replace the current authoritative server and realize seamless connection with the existing DNS, RPKI, PKI system, while providing detailed performance experiment evaluation feasibility.

[0127] Table 2 Comparison of existing technologies

[0128]

[0129] Embodiment:

[0130] The Gossip-based data exchange algorithm proposed by the present application is applicable to the Internet infrastructure resource data exchange scene between different countries and organizations. In order to deal with the serious security risks existing in the centralized structure of the current Internet governance system, an Internet infrastructure resource ownership guarantee community needs to be established between countries and organizations. Under the framework of the community, countries and organizations cooperate with each other, build a distributed network by deploying multiple nodes instead of the traditional single authoritative system, exchange each other's resource data between nodes and apply it to local related information services and security support system. However, in this scenario, it is difficult for nodes to establish mutual trust relationship flexibly, and how to ensure that each member can still receive correct and consistent data in a low trust environment becomes a problem to be solved.

[0131] To solve the above problems, we propose this data exchange technology for Internet infrastructure resources. Under the framework of this technology, each node can deploy and run the Gossip-based data exchange algorithm locally to complete data exchange and verification. This algorithm allows nodes to configure a set of trusted members autonomously, and verifies the propagation range and consistency of data, ensuring that nodes can still obtain correct and consistent data in a weak trust environment, thereby supporting the construction and operation of the Internet infrastructure resource ownership guarantee community.

[0132] A prototype of the data exchange system for Internet infrastructure resources is implemented, and multiple nodes are deployed in a real network environment for experiments. Each node runs in an independent environment and communicates through HTTP GET / POST. In order to realize a real communication environment across regions, all nodes are deployed on servers in different geographic locations. The server operating system uses Ubuntu 20.04 LTS, and the nodes are deployed through Docker 24.0.7 containerization technology to complete the configuration, generation, and distribution of resource data, communication members, policies, and keys.

[0133] In order to verify the practicability and feasibility of the data exchange technology for Internet infrastructure resources proposed in this paper, experiments are carried out from multiple dimensions to test the node tampering or failure experiment, throughput under different data sizes, delay under different network sizes, and resource consumption under different concurrent requests, etc. The reliability and practicability of the technology are analyzed and evaluated.

[0134] The comparison of the Gossip-based data exchange algorithm proposed in this paper with other FBA protocols and classical BFT protocols is shown in Table 3. Since the Ripple protocol, the Stellar protocol, and the Gossip-based data exchange algorithm all exchange data with members in the trust set, their time complexity is O(M), where M represents the number of nodes in the trust set of the data publisher. The PBFT protocol communicates with all nodes in the global range, and the N nodes that receive data need to broadcast messages to other N-1 nodes, so the time complexity is O(N 2 ). In terms of fault tolerance, the Ripple protocol, the Stellar protocol, and the PBFT protocol use the same fault tolerance mechanism to handle the problems of node tampering and node failure, so their fault tolerance capabilities in these two cases are consistent. However, the Gossip-based data exchange algorithm handles these two problems differently. In the node tampering problem, the algorithm can tolerate up to Byzantine nodes; in the node failure problem, the algorithm can tolerate up to faulty nodes.

[0135] Table 3 Comparison of protocol characteristics

[0136]

[0137] To verify the impact of malicious or faulty nodes on the algorithm, we set up various verification strategies in scenarios with 5, 10, and 15 nodes, evaluating the maximum number of Byzantine nodes and the maximum number of faulty nodes that the system can tolerate. The experimental setup includes a data publisher node, with mutual trust between the publisher and other nodes. Trust relationships between other nodes can be configured based on actual needs. The experimental results are shown in Table 4.

[0138] Table 4 Nodes act maliciously or fail

[0139]

[0140] As can be seen from the table, under different node number scenarios, the system's maximum tolerable number of Byzantine nodes complies with formula (5), and the maximum tolerable number of faulty nodes satisfies formula (12), verifying the correctness of the above conclusions. In addition, by reasonably setting verification strategies at different stages, the system can achieve a high level of fault tolerance.

[0141] The experiment evaluates the impact of data size on system throughput. Data size refers to the number of resource records contained in a file, and throughput represents the number of resource records exchanged per second during an algorithm run. In the live network environment, 5, 8, 10, 13, and 15 nodes were deployed, and different data sizes were set to test the system throughput. The data size was gradually increased to observe its impact on system performance. The experimental results are shown in Figure 1. Figure 3 shown.

[0142] from Figure 3 As can be seen in the figure, system throughput shows a downward trend as data size increases. At the same data size, an increase in the number of nodes also leads to a decrease in throughput. This shows that in a multi-node environment, an increase in data size may introduce additional computing overhead and network communication delays, thereby affecting the overall performance of the system. Specifically, when the number of nodes reaches 15, as the data size increases from 5,000 to 30,000, the system throughput decreases significantly from 420 TPS to 200 TPS. Despite the decrease in system throughput, this algorithm is mainly used for data exchange of basic Internet resources, and in practical applications, this throughput can well meet business needs.

[0143] Figure 4The graph shows the relationship between the number of nodes and latency for different data sizes. As can be seen from the graph, the algorithm's latency increases linearly with the number of nodes, indicating that the algorithm's time complexity is O(N). The increase in system latency is primarily due to the time overhead associated with data confirmation between nodes. As the number of nodes increases, each node needs to communicate with more nodes, increasing the overall system's response time. Furthermore, for the same number of nodes, latency increases with data size. Specifically, when the data size is 30,000, the latency nearly doubles from 70 seconds to 140 seconds as the number of nodes increases from 5 to 15. However, when the data size is 5,000, the latency remains relatively stable at around 10 seconds as the number of nodes increases. These results demonstrate that for resource data of varying sizes, the system can complete the data exchange process within a bounded timeframe with acceptable latency, validating the feasibility of the algorithm with polynomial time complexity of O(N).

[0144] Figure 5 We further analyzed the latency contribution of each stage for different data sizes. As can be seen from the figure, data reception (Stage 2) and consistency verification (Stage 4) account for the largest portion of latency throughout the algorithm's execution. This result indicates that data reception and consistency verification are the most critical steps in the consensus process, accounting for the majority of system latency. As data size increases, the latency contribution of these two stages becomes more pronounced, indicating that the time overhead of data reception and consistency verification increases significantly when processing more transactions concurrently, making them the primary source of latency for the entire algorithm.

[0145] To verify the scalability and data publishing efficiency of the system, we conducted a large-scale deployment test experiment in a globally dispersed scenario. The experimental content included the system construction time and data publishing time. The experimental data covered a range of 10 to 1000 nodes. The experimental results are as follows: Figure 6 shown.

[0146] Judging from the system setup time data, as the number of nodes increases, the system setup time shows a certain growth trend. Specifically, when the number of nodes increases from 10 to 100, the system setup time increases from 12.95 seconds to 13.24 seconds, a smaller increase, and the system setup time is relatively stable. This is due to the parallel approach used when building the system. When the number of nodes further increases to 500 and 1000, although the system setup time increases to 25.6 seconds and 49.6 seconds respectively, it still remains within an acceptable range overall, with good scalability and practicality.

[0147] The graph of data release time shows that the release time increases significantly with the increase in the number of nodes. Specifically, when the number of nodes increases from 10 to 50, the release time increases from 62 seconds to 72 seconds, showing an approximately quadratic growth trend. When the number of nodes further increases to 100 and 1000, the release time increases roughly linearly. This shows that when the number of deployed nodes is small, factors such as data transmission and verification mechanisms may have a more significant impact on data release, resulting in a larger increase. When the number of nodes reaches a certain number, this part of the impact can be ignored, and the data release time is almost proportional to the number of nodes. Although the expansion of the node scale leads to a linear increase in data release time, actual data shows that even if the deployment node reaches 1000, the release time can still be maintained within 30 minutes, which can meet the needs of actual applications.

[0148] We also evaluated the server resource consumption during the algorithm runtime to understand whether it would cause a large burden on the server. In this experiment, the number of concurrent transactions was set to 0, 20, 40, 60, 80, and 100, and the server configuration was 2 cores and 2GB of memory. The experimental results of the average CPU and memory usage are shown in Figure 2. Figure 7 shown.

[0149] As shown in the figure, when the number of concurrent transactions is 0 (i.e., when the server is operating normally), the average CPU utilization is approximately 3%, and the memory utilization is approximately 77%. As the number of concurrent transactions increases, the CPU utilization gradually increases, while the memory utilization remains almost unchanged, showing no significant impact. When the number of concurrent transactions reaches 100, the server's CPU utilization is approximately 45%. While this utilization is high, it is still within an acceptable range given the server's low configuration. Overall, data exchange technology for Internet infrastructure resources can run smoothly on servers with existing hardware configurations, without placing an excessive resource burden on the servers.

Claims

1. A data exchange system for Internet basic resources, characterized by: The initial state of the data exchange system is defined as: Each node in the system configures the communication member set and the trust member set, generates a key pair locally and obtains the public key of the communication member; Administrators configure custom verification conditions, gossip cycles, and anti-entropy synchronization cycles based on actual application requirements; Each node periodically propagates Gossip metadata, randomly selects k nodes from the communication member set, and sends its own known resource data list; at the same time, each node randomly selects a node from the trusted member set according to the configured anti-entropy synchronization period to exchange the complete known resource data list, obtain relevant resource data, and repair the differences; The data publisher of the data exchange system is defined as: The data publisher generates the corresponding resource data, adds a digital signature to it, and publishes it together with the original data on the local server, allowing any node in the system to access and download it; The publisher needs to update the version number of the data to be published based on historical release information. The version number includes a date and a number. Resource data is named by the data identifier and version number and is unique globally. A timer is set to wait for other nodes to receive the data. After the timer expires, the data publisher receives the feedback notification from the message queue and verifies its signature. Nodes that pass the verification are written into a "receiver list," which contains node identification information, IP addresses, and digital signatures. During this process, the publisher only needs to confirm the credibility of the notification source and does not need to compare the consistency of the data disclosed by the recipient with the original data. This process is used to assess the dissemination scope of the data and determine whether it meets the "sufficient disclosure" standard based on the set custom verification conditions. If the receiving list meets the verification conditions, the publisher adds a digital signature to it and publishes it on the local server. Otherwise, the verification failure result is fed back to the corresponding node in the receiving list; a timer is set and waits for other nodes to verify the receiving list; After the timer expires, the data publisher verifies the consistency verification results one by one based on the feedback from each receiver, and writes the information of the nodes that have passed the verification into the "public list"; Then, the public list is judged to see whether it meets the public conditions according to the preset custom test conditions; If the conditions are met, the data can be considered to have been widely disseminated and the trust members have received the correct data; The data receiver of the data exchange system is defined as: The node compares the received metadata with the local version. If missing data is found, the recipient needs to verify whether the data source is a trusted member and whether the data version number is higher than the local version. If the verification is successful, the node obtains the missing data and its signature from the data publisher and updates the local Gossip metadata; During data reception, the node needs to verify whether the data publisher is in the pre-configured trust set and compare it with the locally stored version number to determine whether it is an updated version; If new data is found to be published, the node obtains the data and its signature and verifies the signature. If the verification is successful, the data is digitally signed and published on the server. Otherwise, it is written into the exception log. Finally, the node actively pushes the data reception status to the publisher and sets a timer. After the timer expires, the data receiver obtains the receiving list from the publisher and verifies the signature list in it; This process is used to verify the consistency of data received and serves as a criterion for determining whether the data is "sufficiently consistent"; Verification is performed using a joint signature verification mechanism based on SMPC or a node-by-node signature verification mechanism. The SMPC-based joint signature verification mechanism is centered on the data publisher, and all nodes within the publisher's trust range can serve as verifiers. The publisher can adjust the trust set based on the verification results; the node-by-node signature verification mechanism is centered on the data receiver. If the verification passes, it proves that the content is consistent, and the node is written into the "consistency verification list." After the verification is completed, the data receiver verifies the consistency verification list according to the custom verification conditions and feeds back the results to the publisher.

2. The data exchange system for Internet basic resources according to claim 1, characterized in that: The data exchange system also has a digital signature management module with simple structure, security, reliability and high readability. The digital signature management module is designed with a self-configured signature set: On the one hand, in the data exchange scenario, each data exchange process is regarded as an independent transaction. Since each transaction is independent of each other, the self-configured signature set stores the signature information of a single transaction in one file for centralized signature. The signature sets of different transactions do not need to be connected to each other, which simplifies the data structure. On the other hand, the self-configured signature set only retains the necessary node information and its corresponding signature data in the content record, and optimizes the record format to improve readability, making it easier for users to identify and track abnormal nodes, and digitally sign the signature set file as a whole.

3. The data exchange system for Internet basic resources according to claim 2, characterized in that: During the verification process, the data exchange system is designed with a joint signature verification mechanism based on secure multi-party computation (SMPC) and a node-by-node signature verification mechanism to meet different application requirements. This is to balance the security and flexibility of the algorithm as a whole. Specifically: The SMPC-based joint signature verification mechanism aims to achieve decentralization and prevent Byzantine nodes from doing evil. The verification process mainly includes the following two steps: 1) For each node signature record in the signature set, based on the threshold secret sharing mechanism (such as Shamir SecretSharing), the node's public key information Q, signature (r, s) and message digest H(data) are split into several secret fragments and distributed to pre-selected verification nodes respectively; 2) Each verification node jointly executes a signature verification function based on a multi-party secure computation protocol (such as ECDSA under MPC) without revealing the contents of the secret fragments it holds. This function does not expose intermediate data during the calculation process and only outputs a Boolean value to determine whether the signature is valid. This verification process uses a (k,n) threshold strategy, where n represents the total number of nodes participating in the verification and k is the minimum number of nodes required to complete the verification, thereby achieving Byzantine fault tolerance and decentralization of the verification process. The node-by-node verification mechanism is used to adapt to the requirements of different business scenarios. That is, each signature can be verified locally or in a trusted environment in sequence, and the validity is judged according to the configurable minimum number of valid signatures. It is applicable to the rapid verification of signature sets in scenarios where computing resources are scarce or distributed computing is not required.

4. The data exchange system for Internet basic resources according to claim 3, characterized in that: The data exchange system is also designed with a multi-copy verification mechanism. The multi-copy verification mechanism is used as the basis for judging the successful publication of data. For different scenario requirements, two verification mechanisms, namely quantity threshold verification and specific node verification, are given. Nodes can flexibly configure the verification method according to actual needs.

5. The data exchange system for Internet basic resources according to claim 4, characterized in that: The quantity threshold verification mechanism depends on counting the number of nodes that receive data. During the operation of the Gossip-based data exchange algorithm, from the propagation range verification stage (the third stage) to the "sufficiently public" and "sufficiently consistent" verification stage (the fifth stage), nodes need to set different trust set member ratios as verification strategies at each stage, denoted as t3, t4, and t5 respectively; in this algorithm, the data publisher and its mutually trusted member set are defined as a "federation". Based on the fact that the trust set is configured by nodes independently and is not subject to any centralized constraints, different federations can be independent of each other and have no intersection.

6. The data exchange system for Internet basic resources according to claim 5, characterized in that: The specific implementation process of the quantity threshold verification mechanism in the case of a single federation is as follows: Suppose a federation consists of n nodes that are mutually trusted with the data publisher, and there is a situation where these n nodes do not trust each other; at this time, the trust set of the publisher should contain n nodes, and the trust sets of other nodes should contain n - m (0 ≤ m < n) nodes; Analyze two situations. First, consider the situation where there are f Byzantine nodes in the system. The Byzantine nodes will maliciously tamper with data content or send false notifications; the defined Byzantine fault tolerance criteria are as follows: 1) If a normal node passes the verification in the consistency verification stage, then the data should be regarded as sufficiently public and sufficiently consistent; 2) If a normal node fails the verification in this stage, the data is invalidated to ensure the correctness of the algorithm. In this case, the number of nodes in different lists can be expressed as follows: Number of nodes in the consistency verification list = n - f - 1#(1) Analyze the worst-case scenario, that is, all Byzantine nodes attempt to tamper with data and send false notifications to the publisher before the end of the consistency verification stage; in the propagation range verification stage, if the received list verification passes, the algorithm will enter the next stage; otherwise, the publisher actively terminates the algorithm; since the verification result of this stage does not affect the correctness of the algorithm, the number of nodes in the received list is not calculated. In the worst case, all receivers report that they have obtained and published the data. Therefore, the number of nodes in the receiving list is n, and the number of nodes in the consistency verification list is nf-1. If the non-Byzantine nodes pass the consistency verification phase, all Byzantine nodes attempt to report verification failures to prevent the data from being published. In this case, the number of nodes in the public list is nf. Conversely, if the Byzantine nodes report that the verification has passed, the number of nodes in the public list is f. To ensure the correctness of the algorithm, the following constraints must be met when passing the consistency verification phase: If a node fails verification during the consistency verification phase, the following conditions must be met: In the above analysis, formula (3) ensures that non-Byzantine nodes can pass verification during the consistency verification phase. If they pass verification, the Byzantine nodes will not affect the algorithm execution results. Formula (4) ensures that the final data release results will not be incorrect due to the excessive number of Byzantine nodes. In summary, under the premise of ensuring the correctness of the algorithm, the maximum number of Byzantine nodes that a federation consisting of N = n + 1 nodes can tolerate can be expressed as: Consider the situation where there are d nodes down in the system. At this time, the lists of normal nodes should satisfy: Number of receiving list nodes = nd#(6) Because down nodes cannot receive data or feedback messages, the number of nodes in the receiving list is nd, and the number of nodes in the consistency verification list is nd-1. If all normal nodes pass the consistency verification, the number of nodes in the public list is nd, otherwise it is empty. To ensure that data passes the verification successfully, the following conditions must be met: Based on the above analysis, in a federation consisting of N = n + 1 nodes, the maximum number of down nodes allowed to ensure successful data disclosure cannot exceed: Specific node verification relies on the selection and evaluation of specific nodes. During the verification process, the verification result is considered valid only when all selected nodes pass the verification. Each node selects several nodes with the highest trust level as a specific verification set based on the trust set.

7. The data exchange system for Internet basic resources according to claim 4, characterized in that: The specific node verification mechanism is used to improve the accuracy of the verification process. If the verification is successful, all nodes in the verification set will receive consistent data. This mechanism is used to further screen a smaller set of nodes based on the trust set, reducing the impact of Byzantine nodes on the verification results.

8. A data exchange system method for Internet basic resources, characterized by: The method includes steps corresponding to the program module of a data exchange system for Internet basic resources according to any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and the computer program is configured to implement the steps of the method for a data exchange system for Internet basic resources as claimed in claim 8 when called by a processor.

Images