Today, the Internet has developed into a vast network that spans the globe and connects billions of devices, 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 reliably and credibly, 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.
-
The Public Key Infrastructure (PKI) associates corporate identity information and other data 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 intermediate layer, which in turn endorse leaf nodes, establishing a trust relationship that is passed down from the root to the leaves. For 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 the security of BGP. RPKI employs a centralized, hierarchical structure, and a detailed introduction to the design of the RPKI system is shown in (b). RPKI has IANA as the root node, with the five major regional Internet registries (RIRs) as second-layer nodes, potentially including national NIR nodes below, and various operators as leaf nodes. The top-down trust relationship of 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 the 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 various top-level domain servers as intermediate nodes and authoritative domain servers as leaf nodes. The security extension of the DNS system, DNSSEC, still relies on the system structure of DNS, 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 serve as the trust anchors, 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 example, a central node could endorse trust for nodes in other countries, revoke endorsements, or grant trust to fraudulent nodes, all of which could 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 struggle to remain completely neutral 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 achieves 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 is as a decentralized platform that supports decentralized network applications. D utilizes the following capabilities of distributed ledgers to construct 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, if that node abuses its privileges, it will be replaced by other nodes), ensuring that all nodes are equal in status in the long term. 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 that runs 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) Capability for trustworthy transactions: Accounts can transfer funds to each other through transactions, endowing distributed ledgers with inherent value transfer capabilities. Utilizing this capability not only provides a technical platform for third-party developers but also enables the monetization of technology.
3.1 Technical requirements for D's distributed ledger: 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 and are open for 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 inefficient consensus and a plethora of 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 may 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, and 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 difficult to adapt to the dynamism of a large system. For example, Hyperledger requires manually static configuration of node lists, and updating the list necessitates system restarts, which may introduce centralized management configurations.
3.2 Access control mechanism: Existing public chains lack access mechanisms but offer good dynamism, allowing nodes to join and leave dynamically. Consortium chains have access mechanisms but generally exhibit poor scalability, with a limited capacity for accommodating nodes. To allow only qualified organizations (such as operators, enterprises, universities, etc.) to dynamically join the system and apply for resources, a simple mechanism is proposed that simultaneously implements an endorsement access mechanism and dynamic node management. This mechanism allows existing endorsing nodes in the D system to endorse new nodes or cease endorsement, thereby facilitating node entry and exit.
The basic principle of this mechanism is illustrated in Figure 4. The D system initializes with a list of endorsers, which records the information of nodes capable of endorsement within the D system. All nodes wishing to join must obtain endorsement from one or more endorsers before being allowed to join the system. In Figure 4, major regional Internet registries (RIRs) such as AFRINIC, APNIC, ARIN, LACNIC, RIPE NCC, and national registries (NIRs) such as CNNIC, JPNIC, etc., serve as endorsement institutions. Only organizations that are admitted by at least one endorsement institution are qualified to join D, and their account information is 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 and node identifier.
(2) X applies for endorsement from a certain endorser offline and sends its information (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 message to the IP address provided by X to confirm that the endorsement request 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 follows the handshake message standard between nodes in the Ethereum system; this example uses this message, though 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. Secondly, 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 eliminates the centralized powers of these organizations. The above only provides a basic principle for access control; in specific implementations, existing distributed ledger technologies (such as Ethereum) 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 according to different application requirements, and corresponding access control instances can be implemented based on different endorsement institution lists.
These endorsement institution lists and all subsequent information maintained by 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 article 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 for the IP address space. Trustworthy ownership and mapping relationships of IP address prefixes are crucial; otherwise, network attacks such as BGP prefix hijacking and path hijacking may occur. 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 may arise.
Trustworthy and reliable name ownership and name mapping are fundamental to the credibility of 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 the reasonable usage needs of applicants, preventing the exhaustion of the namespace and routing fragmentation during the allocation process. Below, the feasibility of implementing global IP address allocation in a decentralized manner is analyzed.
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 allocable quantity of 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 to apply for a one-year usage right for a /32 IPv6 address and pays 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.
The management of domain names differs from that of IP addresses. First, domain names are hierarchical, while the IP address space is flat; second, the domain name space is practically inexhaustible, whereas the IP address space is limited. For D, the focus should be on the domain name space that belongs to the common assets of humanity, rather than domain names that belong to a specific country or institution. This article 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 are common assets of humanity, and 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 will not be discussed further due to space limitations.
The logic of domain name management can be implemented in a separate smart contract. Unlike IP address applicants (primarily large organizations), 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. Applicants for second-level domains (SLDs) must first generate a pair of public and private keys (the public key is pkX and the private key is skX). They submit their public key pkX and the domain name they wish to apply for (example.com) to a domain name agent A. A first checks whether the domain name is still available; if it is, a transaction is initiated in the distributed ledger stating that pkX is applying 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" into the ledger. The application for a domain name differs from that of an IP address; the former follows a first-come, first-served approach, while the latter requires algorithms to prevent address fragmentation. The annual usage fee for the domain name 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 name agent does not provide services for 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 name holder must sign with their private key to operate the transfer of the relevant domain name. They can apply through intermediary A and transfer through intermediary B, thereby independently maintaining control over the domain name.
Due to the massive and highly dynamic volume of domain resolution data, 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 example.com only stores their 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 Tampering Detection: When a malicious AS hijacks routes by publishing false AS paths, it is difficult to detect the tampering of AS paths through existing BGP itself, leading to routing 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 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 an AS's traffic being hijacked or entering a black hole, only the affected AS would suffer, meaning that the true owner of the AS has no incentive to publish false information. Therefore, the AS neighbor relationship table maintained by the DI system is secure and trustworthy.
Still using 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 for detecting 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 has leaked the prefix 30.30.0.0/16 based on existing BGP. If AS300 prefers AS200 to forward traffic to 30.30.0.0/16, it could lead to traffic being incorrectly attracted to AS200. If AS200's capacity is insufficient, it may cause delays in traffic forwarding or even result in dropped packets.
The credibility of traditional websites is primarily ensured through PKI certificates for 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 provide assurance for 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 offer proof of domain ownership by the website operator for that 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 completely decentralized, enhancing security, while the latter still relies on CAs. In D, a website can simultaneously obtain identity endorsements from multiple CAs to avoid situations where a single CA unilaterally revokes a certificate, causing the website's trust anchor to be compromised. In the worst-case scenario, even if all CAs simultaneously revoke their identity endorsements for a certain node's account, it cannot strip the 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 scheme 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 in the D system by collecting current BGP prefix information and obtaining ownership and ASN mapping relationships without altering the existing IP address allocation system. The specific scheme 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 to the public key pkA, which will be used by other nodes in Step 3 to verify the ownership of that IP address in the D system; second, it binds the IP address 2001:da8:32 to AS100, which will be used by other nodes in Step 3 to verify the legality of the ROA details. The public key information pkA can be carried through an extension of the existing BGP update message; the specific message format will not be elaborated in this article.
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 period of time. For example, it must be stable for more than 5 days within a 10-day period before other nodes will recognize ISPA as the true owner of that address. Once the routing meets the above criteria, ISPA can initiate a transaction to ensure that nodes in the network recognize the credibility of the prefix-related information, avoiding transaction failure.
Step 3: Verification nodes receive the transaction and obtain the IP address prefix, the owner's public key information, and the ASN authorized to declare BGP announcements. The verification nodes then retrieve relevant routing information for that address prefix from the router, including the survival time of the route stored locally, ASN, the public key of the address owner, and other information to verify the transaction information.
If the messages on the router and the transaction messages are consistent, the verification is successful. Once the verification nodes reach a consensus, they 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 routes, writing it into BGP routers to perform 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 unilateral revocation of trust or granting trust to fraudulent nodes by central nodes, which could have destructive impacts on trustworthy services.
6.2 ASN Management and Inter-Domain Neighbor Relationships: The DI system can store ASN ownership information in the distributed ledger without altering the existing ASN allocation system by collecting current BGP information, thereby supporting AS owners in storing trustworthy inter-domain neighbor relationships in the distributed ledger, achieving decentralized management of AS inter-domain neighbor relationships. ASN management is similar to IP address management, and the specific scheme 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 scheme requires extending BGP update messages to carry the public key information of the ASN owner, thereby binding the ASN to its owner; the specific message format will not be elaborated in this article.
(2) ISPB initiates a transaction claiming ownership of ASN 200, stating that 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 period before initiating the transaction, ensuring that nodes in the network recognize the credibility 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 successful verification, they accept the transaction. Once the verification nodes reach a consensus, they store the ASN owner's information in the distributed ledger.
Once ASN ownership is clarified, the ASN owner can initiate transactions regarding inter-domain neighbor relationships for that AS. When verification nodes receive this transaction, they first verify ASN ownership; only the ASN owner can initiate transactions related to the ASN. Once the verification nodes reach a consensus, they 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 tampering 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 facts of domain ownership 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 name 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 that 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 that domain name.
(3) Verification nodes (such as C) receive the transaction and retrieve the corresponding IP address from the current DNS system.
(4) Verifier C establishes a connection with the website and performs verification; once verified, C considers the transaction legitimate.
(5) Once a majority of nodes have verified the transaction, the ownership information of the domain name is written into the D system.
The method of verification depends on the website itself; D imposes no restrictions. This article 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 is successful, it indicates that the private key sk held by the domain owner corresponds to the public key pk published on D, confirming that the private key holder is indeed 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 decrypted random number using the 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 domain ownership is clarified, the domain owner can revoke the published information in the existing DNS system and maintain that information in the D system, thereby providing DNS services as shown in Figure 7.
The above three transitional schemes only illustrate how to synchronize established facts of resource ownership 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, with resources being reclaimed by smart contracts after expiration. The resources in the pool can then enable the fully decentralized management approach described in Section 4. The reclamation and redistribution of resources will be influenced by strategies and games among international institutions, which exceeds the technical scope and will not be discussed further in this article.
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 consistency protocol suitable for Internet infrastructure, SCP; the University of California, Berkeley proposed a decentralized mapping system; and the Decentralized Identity Foundation is promoting decentralized identity systems, all of which have received widespread attention from academia and industry.
In response to the centralization issues of RPKI, Cloudflare has launched RPKI Transparency technology and products, but this only employs post-audit methods to check for malicious behavior by central nodes, failing to provide preemptive prevention. 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) in Spain analyzed the management of IP address space using the Proof of Stake algorithm. Meanwhile, Carlos III University of Madrid (UC3M) has conducted experiments on managing IP address space using blockchain based on Ethereum.
Regarding the centralization issues of the domain name system, several decentralized domain name projects have emerged in the industry, such as Namecoin, BNS (Blockstack Naming System), and ENS (Ethereum Naming Service). 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 alter information unilaterally, harming clients and domain holders. In ENS, although clients can verify resolution results, each request incurs significant verification overhead.
To address the centralization issues of PKI, Google proposed the Certificate Transparency (CT) scheme. This scheme utilizes an additional log system to record the entire history of certificate issuance, while legitimate website operators monitor the issuance behavior of related 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 provide remediation after the fact and cannot fundamentally prevent malicious behaviors arising from centralization issues.