Today, the internet has developed into a vast network that spans the globe, connecting billions of devices and carrying communication tasks that are crucial to production and daily life. To enable two nodes that are far apart and do not know each other to communicate in a trustworthy and reliable manner, the internet provides the necessary infrastructure. From the network layer to the application layer, there are three key infrastructures, as shown in Figure 1.
-
The Border Gateway Protocol (BGP) achieves the fundamental connectivity of the global internet by associating IP address prefixes with autonomous systems and inter-domain topologies, calculating inter-domain routes.
-
The Domain Name System (DNS) maps domain names to IP addresses, linking application layer service names with network layer addresses, allowing services to be accessed over the network.
-
Public Key Infrastructure (PKI) associates enterprise identity information and other information with public keys, linking network communication entities with real-world identities, making communication trustworthy.
Currently, these infrastructures or the secure and trustworthy systems they rely on adopt a centralized design as shown in (a). The basic principle of this design is that a single trusted root node serves as the trust anchor for the entire system, endorsing trusted nodes in the middle layer, which in turn endorse leaf nodes, passing the trust relationship from the root down to the leaves. Taking BGP as an example, although BGP itself is a distributed protocol, its trust foundation is the Resource Public Key Infrastructure (RPKI), which is used to verify the legitimacy of BGP address prefix announcements and ensure BGP security. RPKI employs a centralized, hierarchical structure, with IANA as the root node, the five major regional Internet registries (RIRs) as second-layer nodes, and potentially national NIR nodes below, with various operators as leaf nodes. The top-down trust relationship in RPKI is supported by resource certificates (RC) issued at each level, which declare a node's ownership of a specific IP address prefix. Ultimately, leaf nodes that possess resource certificates can authorize a specific Autonomous System (AS) number by publishing Route Origin Authorizations (ROAs), allowing that AS to announce the IP address prefixes held by that node in outgoing BGP messages. Accordingly, BGP routers can use the certificate chain formed by PRKI to verify the legitimacy of BGP prefix announcements upon receiving BGP messages. Similarly, the DNS system is also a hierarchical system centered around root servers, with top-level domain servers at various levels serving as intermediate nodes, and authoritative domain servers as leaf nodes. The security extension of the DNS system, DNSSEC, still relies on the DNS system structure, performing public key endorsements and signatures in a top-down manner, with its basic security principle remaining centralized. The PKI system also adopts a hierarchical structure with a central root node.
Centralized systems like the above have some fundamental issues. In such systems, the centralized authoritative nodes are the trust anchors of the system, wielding excessive power that allows them to unilaterally revoke certificates or digital signatures, removing trust endorsements from subsequent nodes or granting trust to fraudulent nodes, thereby harming the interests of legitimate nodes. Since these infrastructures are global, malicious actions by a central node can have worldwide negative impacts. For instance, a central node could endorse trust for nodes in other countries, revoke endorsements, or grant trust to fraudulent nodes, all of which would have destructive effects on trustworthy services in other countries. These central authoritative nodes may have various motivations for such actions, such as being compromised by hackers or misconfigured by administrators. A central node may also fail to remain completely neutral, exhibiting bias due to conflicts of interest, political, or legal reasons. Below are some real-world security incidents caused by the aforementioned centralized architecture.
The distributed ledger layer provides decentralized foundational capabilities for the namespace management layer, primarily focusing on building a decentralized underlying platform. The namespace management layer realizes the decentralization of the internet namespace on the foundational platform provided by the distributed ledger layer. At the same time, it provides a trustworthy foundation for application layer apps that rely on these namespaces, enabling application development that is closer to user needs.
In recent years, distributed ledger technologies represented by blockchain have developed rapidly. However, the more important value of distributed ledgers lies in serving as a decentralized platform that supports decentralized network applications. D utilizes the following capabilities of distributed ledgers to build decentralized internet infrastructure.
(1) Decentralized system structure: There are no constant privileged nodes in the system (although some nodes may have greater power for a period of time, if that node abuses its privileges, it will be replaced by other nodes), ensuring that all nodes are equal in status in the long run. This aligns with the trust model of decentralized internet infrastructure.
(2) Distributed consensus mechanism: This is the core of distributed ledger technology, where all nodes reach consensus through a decentralized mechanism. D requires a consensus mechanism to ensure the uniqueness of ownership of network resources such as the internet namespace and the consistency of related applications.
(3) Smart contracts: A computing environment running on distributed ledgers, advanced smart contracts can support Turing-complete computing models, theoretically supporting any application. D's management of the internet namespace requires complex logic, while the open application layer needs to support arbitrary applications, thus necessitating smart contract technology.
(4) Trusted transaction capability: Accounts can transfer value to each other through transactions, which endows distributed ledgers with inherent value transfer capabilities. Utilizing this capability can provide a technical platform for third-party developers and enable technical monetization.
3.1 Technical requirements for D on distributed ledgers: Current distributed ledgers are mainly divided into two categories: public chains and consortium chains. However, both types of distributed ledgers have certain issues that prevent them from being directly used in the D system. Public chains, represented by Bitcoin and Ethereum, operate on the public internet, open to any node to join, exhibiting good dynamism. However, due to the lack of restrictions on joining nodes, the number of nodes becomes excessively large, and the system becomes overly exposed, leading to low consensus efficiency and frequent malicious attacks.
As a management platform for core internet resources (IP addresses, ASNs, domain names, etc.), from a security perspective, it is undesirable for anyone to join without constraints; from a demand perspective, not everyone has a need to apply for core resources (for example, only ISPs or larger organizations have a need to apply for large blocks of addresses).
Public chains do not meet these requirements. Consortium chains, represented by Hyperledger, generally operate in localized networks, allowing only certified nodes to join, resulting in fewer nodes. Compared to public chains, consortium chains offer higher performance and better security; even if issues arise, accountability and resolution can be pursued through certification channels. However, consortium chain technology is difficult to apply directly to D. This is because D, as the infrastructure of the global internet, involves a very large number of participating nodes. Current consortium chains rely on statically configured admission lists, making it challenging to adapt to the dynamism of a large system. For example, Hyperledger requires manual static configuration of node lists, and updating the list necessitates system restarts, which can introduce centralized management configurations.
3.2 Admission control mechanism: Existing public chains lack admission mechanisms but exhibit good dynamism, allowing nodes to join and leave dynamically. Consortium chains have admission mechanisms but generally have poor system scalability, with a limited number of nodes they can accommodate. To allow only qualified organizations (such as operators, enterprises, universities, etc.) to dynamically join the system and apply for resources, a mechanism that simultaneously implements endorsement admission and dynamic node management is proposed. This mechanism allows existing endorsing nodes in the D system to endorse new nodes or stop endorsing them, thus facilitating node joining and leaving.
The basic principle of this mechanism is illustrated in Figure 4. The D system will initialize with an endorser list that records the information of nodes capable of endorsing within the D system. All nodes wishing to join must obtain endorsement from one or more endorsers to be allowed into the system. In Figure 4, major regional internet registries (RIRs) such as AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC, and various national registries (NIRs) like CNNIC, JPNIC, etc., serve as endorsement institutions. Only organizations that have been admitted by at least one endorsement institution are eligible to join D, and their account information will be written into the admission node list maintained by smart contracts. In practice, the initialization of this list requires offline communication and negotiation. The list of endorsement institutions can also be increased or decreased, determined by mutual voting among the endorsement institutions. The specific joining process is as follows.
(1) If a certain NSPX wants to join the D system, X must first download the D system's blockchain client locally and generate its account (account) and node identifier (node ID).
(2) X applies for endorsement from a certain endorser offline and sends its information (the IP address information of the D device, X's account, and node identifier) to a certain endorser A. At the same time, X must also obtain relevant information about endorser A offline (such as a public key that can prove its identity).
(3) Endorser A initiates an endorsement transaction in the D system, writing X's node identifier information into the blockchain's endorsement list. The endorsement list stores all node endorsement information in the current system.
(4) Endorser A sends a node inquiry (ping node) message to the IP address provided by X to confirm that the endorsement application was indeed initiated by X; the node inquiry message must also carry A's signature for X to verify A's identity. The node inquiry message is based on the handshake message between nodes in the Ethereum system; this message serves as an example, as different systems may have different messages, but the functionality is generally similar.
(6) X discovers nodes based on the endorsement list and relevant node discovery algorithms, connecting to the D system. Although RIRs and NRs still exist as endorsers in the D system, their functions differ from those of existing centralized systems like RPKI. First, in D, these endorsers only perform identity endorsement and admission certification for applying organizations, without dominating resource allocation. Once an organization is admitted, it can independently apply for and own relevant resources, and resource ownership does not depend on endorsers. Second, an organization can receive endorsements from multiple endorsement institutions, so even if one endorsement institution unilaterally revokes its endorsement, the organization still meets the admission criteria.
Thus, D significantly reduces the centralized power of these organizations. The above only provides a basic principle for admission control; in specific implementations, existing distributed ledger technologies (such as Ethereum, etc.) can be modified and enhanced according to the above principles, or customized distributed ledgers can be implemented based on actual needs. Additionally, multiple endorsement institution lists can be designed based on different application requirements, and corresponding admission control instances can be implemented according to different endorsement institution lists.
These endorsement institution lists and all subsequent maintenance information of the D system can be implemented through smart contracts or similar methods. In summary, the above issues need to be further detailed and deeply resolved in future research and specific implementations, and this paper will not elaborate further.
4 Namespace Management Layer: The internet namespace is core to the TCP/IP protocol and is also central to internet infrastructure. The two most important infrastructures of the internet, namely BGP and DNS, revolve around the namespace. BGP maps IP address prefixes to ASNs (AS numbers) and AS paths, thereby calculating inter-domain routing of the IP address space. Trustworthy ownership and mapping relationships of IP address prefixes are crucial; otherwise, there will be network attacks such as BGP prefix hijacking and path hijacking. DNS maps the domain name space to the IP address space, allowing services to be accessed at the network layer. Trustworthy domain ownership and mapping relationships are also critical; otherwise, vulnerabilities such as domain cache poisoning will exist.
Trustworthy and reliable name ownership and name mapping are the foundation of trustworthy infrastructure. For this reason, the namespace management layer is positioned as the intermediate layer of the D architecture, ensuring the security and trustworthiness of internet infrastructure through decentralized and trustworthy name ownership and mapping, thereby supporting trustworthy upper-layer applications.
4.1 Management of IP Addresses and AS Numbers: The current trustworthy infrastructure for IP addresses and ASNs is RPKI. RPKI adopts the centralized tree structure of the global IP address allocation system, ensuring the uniqueness of ownership rights for IP addresses and ASNs through central authoritative organizations while assessing applicants' reasonable usage needs to prevent exhaustion of the namespace and routing fragmentation during allocation. The feasibility of implementing global IP address allocation in a decentralized manner is analyzed below.
If the initial ownership of an IP address is determined, the transfer of the IP address can be completed through transactions on the distributed ledger, a relatively simple process that will not be elaborated here. This section mainly introduces the initial allocation process of addresses. Since the IPv4 address space has been fully allocated, this discussion focuses on IPv6 addresses. In the D system, the basic unit for IPv6 address allocation is considered to be /32, which is similar to the number of allocable 32-bit ASNs.
The system for IPv6 address allocation is shown in Figure 5. Organizations that have been admitted can initiate IPv6 address applications. Taking ISPB as an example, it first initiates a distributed ledger transaction, applying for a one-year usage right for a /32 IPv6 address and paying the annual usage fee. Other nodes receive this transaction and check the applicant's legitimacy and annual fee through smart contracts, using a sparse delegation algorithm to calculate a suitable address prefix for ISPB. The basic function of this algorithm is to calculate continuous address space for each applicant, thereby preventing address fragmentation and routing bloat. Since the algorithm is deterministic, the allocation of addresses across the network is consistent and unique. Before the usage right expires, the applicant must initiate a renewal transaction and pay the annual fee; otherwise, the prefix will be returned to the address pool by the smart contract.
Domain name management differs from IP address management. First, domain names are hierarchical, while IP address space is flat; second, the domain name space is practically inexhaustible, while the IP address space is finite. For D, the primary concern is the domain name space that belongs to the common assets of humanity, rather than domain names belonging to a specific country or organization. This paper focuses on generic second-level domains (e.g., example.com, example.net, etc.). This is because:
- Generic top-level domains such as .com and .net belong to the common assets of humanity, and the corresponding second-level domains can be freely applied for.
- Once the ownership of a second-level domain is determined, the corresponding third-level domains are managed within the same management domain and are considered private assets, falling outside the scope of decentralized management. Additionally, country code top-level domains (e.g., .cn, .jp) require offline negotiation and are not discussed in this paper due to space limitations.
The logic of domain name management can be implemented in a separate smart contract. Unlike IP address applicants (primarily large organizational structures), domain name applicants include a large number of individuals and small organizations, which have a lower willingness to deploy distributed ledgers and bear maintenance costs. Therefore, the current domain management system's domain name intermediaries can be utilized to replace applicants in the decentralized domain name application process while avoiding the concentration of power.
Decentralized domain name applications and transfers are illustrated in Figure 6. The applicant for a second-level domain (SLD) must first generate a pair of public and private keys (the public key is pkX and the private key is skX). It submits its public key pkX and the domain name it wishes to apply for (example.com) to a domain name agent A. A first checks whether the domain name is still available; if it is, it initiates a transaction in the distributed ledger stating that "pkX applies for the domain name example.com." Other nodes receiving the transaction must also check the availability of the domain name; if available, they write "the owner of example.com is pkX." The application for a domain name differs from that of an IP address; the former adopts a first-come, first-served approach, while the latter requires algorithms to prevent address fragmentation. The annual usage fee for domain names and the handling of renewals and expirations are similar to those for IP addresses and will not be elaborated further.
Although D employs domain name intermediaries to manage domain names on the distributed ledger instead of the applicants, the ownership of the domain name remains under the control of the applicant, avoiding centralization issues. This is because what is written in the distributed ledger is that the domain name belongs to pkX, and only the applicant holding the corresponding private key skX can prove ownership of the domain name. Even if the domain agent does not provide services to the applicant, the applicant can manage the domain name through other intermediaries without being bound or held hostage by the intermediary. For example, in the domain transfer illustrated in Figure 6, the domain holder must sign with the private key to operate the transfer of the relevant domain name. The application can be through intermediary A, and the transfer can be through intermediary B, thus independently maintaining control over the domain name.
Due to the enormous volume of domain resolution data and its high dynamism, it is impractical to store all resolution data (such as mapping the domain name www.example.com to certain IP addresses) entirely on the distributed ledger. Therefore, D only stores the most critical information for secure domain resolution in the distributed ledger. The unique owner of the domain name example.com only stores its public key and the address of the authoritative name server for the domain in the distributed ledger, as shown in Figure 7. The characteristics of this information are that it occupies little storage space and has low dynamism, which will not pose significant challenges to the performance and scalability of the distributed ledger. In contrast, large volumes of dynamic information are stored on authoritative servers.
5.2 BGP Path Modification Detection: When a malicious AS hijacks routes by publishing false AS paths, it is difficult to detect AS path tampering through existing BGP itself, leading to routes being hijacked to malicious ASs, causing significant harm. Figure 9 provides an example of BGP path tampering, where AS400 forges the prefix 20.20.0.0/16 and publishes a false AS path (400,200). AS600 receives two AS paths to reach 20.20.0.0/16: (400,200) and (500,100,200). Based on the shortest path principle, AS600 prefers AS400 to reach 20.20.0.0/16. As a result, traffic destined for 20.20.0.0/16 in AS600 is hijacked to AS400. Based on the DI system, the following BGP path verification method can be used to detect BGP path tampering. The owner of an AS can publish its neighbor relationships with other ASs on the DI through transactions, and other nodes will verify whether the publisher is the true owner of that AS. Once verified, the AS's neighbor relationships will be written into the D system by other nodes. Since publishing false information would lead to traffic being hijacked or entering a black hole, harming only that AS, the true owner of the AS has no motivation to publish false information, making the AS neighbor relationship table maintained by the DI system secure and trustworthy.
Continuing with Figure 9 as an example, suppose the neighbor relationship published by AS200 is shown in Table 1. When AS600 receives the AS path (400,200) published by AS400, it can verify the trustworthiness of the inter-domain neighbor relationship between AS200 and AS400 through Table 1. Clearly, AS200 has not published a neighbor relationship with AS400, indicating that AS200 has not established an inter-domain neighbor relationship with AS400.
5.3 BGP Route Leak Detection: The Internet Engineering Task Force (IETF) standard RFC7908 classifies BGP route leaks. This section provides methods to detect the first four types of route leaks defined by this RFC. The specific types of route leaks are as follows:
- An AS announces routes received from a provider to other providers;
- An AS announces routes received from peers to other peers;
- An AS announces routes received from a provider to its peers;
- An AS announces routes received from peers to its provider.
AS200 receives the prefix 30.30.0.0/16 from provider AS100 and announces it to its peer AS300. This behavior corresponds to the aforementioned type 3 BGP route leak, as shown in Figure 10. AS300 cannot identify that AS200 leaked the prefix 30.30.0.0/16 based on existing BGP. If traffic to 30.30.0.0/16 is preferentially forwarded by AS300 to AS200, it could lead to traffic being incorrectly attracted to AS200. If AS200's capacity is insufficient, it may cause delays in traffic forwarding or result in dropped packets.
The trustworthiness of traditional websites is primarily ensured through PKI certificates that guarantee two types of information: domain ownership and the true identity of the operator. Certificates that only provide proof of domain ownership are called DV certificates, while those that guarantee both types of information are called EV certificates, with the latter generally considered more trustworthy. Based on the domain management introduced in Section 4, D can utilize the information provided by smart contracts to demonstrate that the website operator owns the domain, meaning that DV certificates no longer rely on any third-party digital certificate authorities (CAs). Website operators can independently provide users with information related to smart contracts to prove their ownership of the domain.
On this basis, a CA role can be introduced into D as a participating node. CA nodes can publish identity endorsement information for other nodes' accounts through smart contracts. Logically, this identity endorsement information is completely independent of the domain management system information. If a node possesses identity endorsements while also owning certain domains, it can simultaneously provide its website users with relevant domain ownership information and identity endorsement information.
Users can verify these two types of information based on D, thereby achieving V certificate-level authentication. It should be noted that the public key used by the website in communication is only bound to domain ownership and not to identity endorsement. This is because the proof of domain ownership has been fully decentralized, enhancing security, while the latter still relies on CAs. In the D system, a website can simultaneously obtain identity endorsements from multiple CAs to avoid the situation where a single CA unilaterally revokes a certificate, which would undermine the trust anchor of the website. In the worst-case scenario, even if all CAs simultaneously revoke their identity endorsements for a certain node account, it cannot deprive the node of its domain ownership; at most, it would downgrade the trustworthiness of the website operated by that account from EV level to DV level, thereby mitigating the impact of unilateral actions by centralized CAs.
Since the allocation and management of existing core internet resources (including IP addresses, ASNs, and domain names) have become established and widely used, it is impossible to transfer everything to the D system at once. This section provides a plan that can evolve from the current centralized resource management approach, gradually achieving decentralized management of core resources without affecting resource usage.
6.1 IP Address Management and ROA Capability: The D system can maintain trustworthy information for subsequent applications by collecting existing BGP prefix information and obtaining ownership and ASN mapping relationships without altering the current IP address allocation system. The specific plan is illustrated in the figure.
Step 1: ISPA obtains the address 2001:da8:32 through the existing IPv6 address allocation mechanism. ISPA publishes a BGP message to other ASs, carrying the address prefix 2001:da8:32, AS path 100, and the owner's public key information pkA. This message effectively serves two functions: first, it binds the IP address 2001:da8:32 with the public key pkA, which will be used by other nodes in Step 3 to verify the ownership of the IP address in the D system; second, it binds the IP address 2001:da8:32 with AS100, which will be used by other nodes in Step 3 to verify the legitimacy of the ROA. The public key information pkA can be carried through an extension of the existing BGP update message; the specific message format is not elaborated in this paper.
Step 2: ISPA initiates a transaction in the D system regarding the ownership of the IP address and ASN mapping relationship. The transaction states that the private key holder corresponding to public key pkA (i.e., ISPA) is the owner of the IPv6 address 2001:da8:32 and has published the corresponding prefix through AS100. To prevent malicious actions, the route must remain stable in the network for a certain period of time. For example, it must exist stably for more than 5 days within 10 days; only then will other nodes consider ISPA the true owner of that address. After the route meets the above criteria, ISPA will initiate a transaction to ensure that nodes in the network recognize the trustworthiness of the prefix-related information, avoiding transaction failure.
Step 3: Verification nodes receive the transaction and obtain the IP address prefix, owner's public key information, and ASN authorized to make BGP announcements. The verification nodes then retrieve relevant routing information for the address prefix from the router, including the survival time of the stored route, ASN, and the public key of the address owner, to verify the information in the transaction.
If the messages on the router and the transaction messages are consistent, the verification passes. After reaching consensus, the verification nodes write the ownership information of the IP address and ROA information into the distributed ledger. Through this method, the ROA for the route is stored in the distributed ledger. Various networks can read the ROA and generate a verification list for the route, writing it into BGP routers for BGP source address verification, enhancing routing security.
The owner of the address has complete control over the ROA and does not rely on any third-party authority, avoiding the destructive impact of a central node unilaterally revoking trust or granting trust to fraudulent nodes on trustworthy services.
6.2 ASN Management and Inter-Domain Neighbor Relationships: The D system can store ASN ownership information in the distributed ledger by collecting existing BGP information without altering the current ASN allocation system, thereby supporting AS owners in storing trustworthy inter-domain neighbor relationships in the distributed ledger and achieving decentralized management of AS inter-domain neighbor relationships. ASN management is similar to IP address management, and the specific plan is illustrated in Figure 12.
(1) ISPB obtains ASN 200 through the existing ASN allocation mechanism. When ISPB publishes prefix information to other ASs, it carries ASN 200 and the public key information pkB of the ASN owner. This plan requires extending BGP update messages to carry the public key information of the ASN owner, thereby binding the ASN and owner relationship; the specific message format is not elaborated in this paper.
(2) ISPB initiates a transaction stating "the private key holder corresponding to public key kB (i.e., ISPB) is the owner of AS200." To prevent malicious actions, the ASN information must remain stable in the network for a certain period before initiating the transaction, ensuring that nodes in the network recognize the trustworthiness of the ASN owner information, avoiding transaction failure.
(3) Verification nodes receive the transaction and obtain the public key information of the ASN owner based on the ASN. After verification, they accept the transaction. Once the verification nodes reach consensus, they store the ASN owner's information in the distributed ledger.
Once ASN ownership is clarified, the ASN owner can initiate transactions regarding the AS inter-domain neighbor relationships. When verification nodes receive this transaction, they first verify ASN ownership; only the ASN owner can initiate related transactions. After reaching consensus, the verification nodes store the AS inter-domain neighbor relationships in the distributed ledger, as shown in Table 1. Trustworthy inter-domain neighbor relationships can be applied to BGP path modification and route leak detection, as detailed in Section 5.
6.3 Domain Name Management: D can initialize domain ownership in the D system based on the established domain ownership status without altering the existing domain allocation system. The basic principle is illustrated in Figure 13.
(1) Assuming a user A has obtained the domain name example.com through the existing domain management system, user A needs to activate this domain and maintain the corresponding website's IP address in the existing DNS system. The corresponding website (taking www.example.com as an example) must have the capability to provide verification information.
(2) User A initiates a transaction in the D system, declaring ownership of example.com and binding the domain name to a public key PK, stating that only the holder of the private key corresponding to public key PK is the owner of the domain name.
(3) Verification nodes (such as C) receive the transaction and retrieve the corresponding IP address of the target website from the current DNS system.
(4) Verifier C establishes a connection with the website and performs verification; upon successful verification, C considers the transaction valid.
(5) After the majority of nodes successfully verify, the ownership information of the domain name is written into the D system.
The verification method depends on the website itself; D imposes no restrictions. This paper provides two ideas for readers' reference. The first method allows the website to publish a random number and the signature corresponding to the related private key sk, enabling the verifier to verify the signature using the public key k obtained from the D system. If the verification passes, it indicates that the owner of the domain holds the private key sk and that the public key pk published on D is a key pair, meaning the holder of the private key sk is the owner of the domain name. The second method allows the website to enable some interactive capability, where the verifier generates a random number, encrypts it with public key k, and sends it to the website, requesting the website to reply with the random number decrypted using private key sk. If the decrypted random number is correct, it indicates that the website possesses the private key sk corresponding to public key PK on the D system.
Once the ownership of the domain name is clarified, the domain owner can revoke the published information in the existing DNS system and maintain that information in the D system, thus providing DNS services as illustrated in Figure 7.
The above three transitional plans only outline how to synchronize the established ownership of resources to the D system. Once the resource ownership information is synchronized to the D system, new resource reclamation capabilities can be added to the D system, allowing resources to be reclaimed by smart contracts after expiration. Resources in the reclamation pool can then enable the fully decentralized management methods described in Section 4. The reclamation and redistribution of resources will be influenced by strategies and games among international institutions, which is beyond the technical scope and will not be discussed in detail in this paper.
The topic of decentralizing internet infrastructure has garnered increasing attention. The Internet Engineering Task Force (IETF) has established the Decentralized Internet Infrastructure Research Group (DINRG). Within DINRG, a team from Stanford University proposed a decentralized consensus protocol suitable for internet infrastructure, SCP[9] ; the University of California, Berkeley proposed a decentralized mapping system[10] ; and the Decentralized Identity Foundation is promoting decentralized identity systems[11], all of which have attracted widespread attention from academia and industry.
In response to the centralization issues of RPKI, Cloudflare has launched RPKI Transparency technology and products[12] , but this only employs post-audit methods to check for malicious behavior by central nodes and cannot prevent it beforehand. The essence of the single-point problem lies in the authority and data of central nodes. DII replaces central authoritative nodes with distributed consensus and central databases with distributed ledgers, fundamentally addressing the centralization issue. The Polytechnic University of Catalonia (UPC) analyzed the use of the Proof of Stake algorithm to manage IP address space[13] . The Carlos III University of Madrid (UC3M) has conducted experiments on managing IP address space using blockchain based on Ethereum[14].
Regarding the centralization issues of the domain name system, there are already several decentralized domain name projects in the industry, such as Namecoin[15] , BNS (Blockstack Naming System)[16] , ENS (Ethereum Naming Service)[17] , etc. These solutions focus on addressing centralization issues but also introduce other problems in the domain resolution process. In Namecoin and BNS, DNS clients still need to unconditionally trust certain local domain resolvers and cannot verify the resolution results. These local domain resolvers can maliciously manipulate clients and domain holders through unilateral information tampering. In ENS, although clients can verify resolution results, each request incurs significant verification overhead.
In response to the centralization issues of PKI, Google proposed the Certificate Transparency (CT) scheme[18] . This scheme utilizes an additional log system to record the entire history of certificate issuance, while legitimate website operators monitor the issuance of relevant certificates in real-time through monitors. If any malicious behavior by a CA occurs, the monitor will alert the legitimate website operators. CT can alleviate the centralization issues of the PKI system to some extent, but since it is a passive defense solution, it can only compensate afterward and cannot fundamentally prevent malicious behavior caused by centralization issues.