## 2 Related Work  
The communication problem of unreachable nodes is not only required in decentralized networks, previous research has proposed some solutions to the communication problem of clients behind NAT or firewall in centralized networks. Packets from a client behind a NAT device are converted to another address by the NAT when they flow out, and conversely a packet received externally cannot be converted because the NAT device does not have this mapping. There are protocols that enable NAT devices to change the mapping table so that the NAT device can actively accept connections from external addresses. Universal Plug and Play (UPnP) [33], NAT-PMP [37] uses the SSDP discovery protocol to broadcast the ports required by the client, so that the NAT device knows and adds the appropriate mapping table, with a larger range any packet can be forwarded. Port control protocol (PCP) [32] controls the mapping table of NAT devices at both ends, making them accept packets from the other node and limiting the range of incoming ports compared to UPnP. In a software-defined network (SDN) [38], network devices including NAT can be controlled by custom programs, so many researches have been done from this perspective to allow two parties communicating with each other to accept each other's packets [39; 40]. However, most ISPs do not open these permissions to users, or the devices themselves do not have these capabilities, and as a normal user it is not possible to use these protocols and cannot achieve end-to-end connectivity. The STUN protocol [30] solves this problem by taking advantage of the nature of the NAT device itself, where a client initiates a specific connection to generate the required records in the NAT device's mapping table, and the NAT device allows incoming connections from another client. The TURN protocol [31] and the NAT cloud [41] research based on it, solves this problem by relaying packets directly from a server in a public network environment, regardless of the type of NAT device, but wastes network resources. WebRTC [42] proposes a framework for peer-to-peer communication in a browser application scenario, and is part of a framework that allows the browser to support client-to-client communication as well. [PERSON] et al. [43] and [PERSON] et al. [44] presents a approach based on IoT-related protocols that enable end-to-end IoT-based communication. These enable direct end-to-end communication across multiple protocols and application scenarios. All of these studies have addressed this problem from the perspective of how to interconnect devices behind NAT, essentially requiring a mutually agreed-upon server through which the two end nodes help establish direct connections or relay connections between them. However, the impact of the added modules on the web application is not taken into account. In a centralized network, all clients have to connect to a server that is reachable by the public network. The server can act directly as a centralized dispatch, making itself or additionally specifying one as a server known to both parties. The above solution is applied to interconnect two clients that are behind NAT. However, in a decentralized network these methods become difficult to use due to the absence of a centralized server. There is some research in decentralized networks that proposes solutions. The use of decentralized PCP and decentralized SDN has been proposed in some studies to help devices at both ends to establish connections [34; 45]. Although it solves the problem of centralization to help establish connections, it is limited by the ISP devices and is not very versatile. In the IPFS [23] underlying communication framework LibP2P [29], UPNP is only responsible for mapping ports. If the connection is still not successful, then he adopts the strategy of relay address, i.e., this node must be guaranteed to be able to communicate with another node. This address must be manually specified by the user, and cannot be arbitrarily based on the content to find the node you want to find.