Sending Network: Reconstructing TCP/IP to Build Web3 Communication Infrastructure

Industry Express
2024-04-15 20:16:38
Collection
In response to the fundamental issues caused by the centralized nature of TCP/IP, Sending Labs is developing a decentralized communication protocol stack that supports direct peer-to-peer communication using wallet addresses, thereby reconstructing internet infrastructure and significantly enhancing security, privacy, and user control.

Overview of the TCP/IP Protocol Stack in Web2

In the Web2 era, communication, computing, and storage together form the cornerstone of the internet. Among them, the TCP/IP protocol stack is the most basic and widely used form of network communication, permeating all levels and providing a unified communication framework and standards from the physical layer to the application layer. Almost all Web2 applications rely directly or indirectly on this system. Therefore, the TCP/IP protocol stack has become the standardized foundation for internet communication.

Issues with the TCP/IP Protocol in the Web2 Era

With the evolution of internet technology, the TCP/IP protocol stack has begun to reveal some structural issues. These flaws are hidden in our daily network usage. For example, when two users communicate through a chat application, the impact of these issues can be specifically demonstrated. Suppose User A sends a message to User B; this message is first split into several data packets and then transmitted through multiple servers on the internet to User B.

  • At the application layer, when a user accesses an application website, they need to rely on DNS to resolve the service address. If DNS is polluted or attacked, the user may mistakenly access a malicious server, leading to privacy breaches or data tampering.
  • At the transport layer, if the certificate authority (CA) relied upon by the SSL/TLS protocol is attacked or loses trust, then communication between users may be intercepted or tampered with by a third party. For example, if a user's message is transmitted through an insecure channel, a hacker may intercept these data packets or even forge malicious information. Additionally, reliance on these centralized CAs introduces trust risks.
  • At the network layer, since the IP addresses of application services are controlled and allocated by a few institutions, the limited availability of IP addresses and their centralized allocation lead to resource control being concentrated in the hands of a few countries and organizations. This not only causes unfair distribution but also makes the entire network architecture vulnerable to centralized control threats.

These are fundamental issues caused by the centralized nature of TCP/IP, which cannot be resolved through piecemeal fixes. We need a comprehensive technological innovation to achieve the decentralization of the protocol stack to address these deep-seated problems. Sending Labs is developing a decentralized communication protocol stack that will reshape the TCP/IP model, supporting direct peer-to-peer communication using wallet addresses, thereby reconstructing internet infrastructure and significantly enhancing security, privacy, and user control.

Building a New Communication Standard for the Web3 Era: Reconstructing the TCP/IP Protocol Stack

In the Web3 era, we need to reconstruct the TCP/IP protocol stack to address the issues in the current system. The Web3 version of the TCP/IP protocol stack will have the following characteristics: First, it will ensure an unlimited supply of IP addresses, avoiding monopolization of resources by a few countries or organizations; second, it will transfer trust authentication at the transport layer to a decentralized mechanism based on blockchain, no longer relying on a single CA certification authority; third, it will migrate key protocols like DNS to the blockchain, freeing itself from dependence on traditional DNS service providers; in addition, it will encourage the public to set up routers to build a decentralized physical layer infrastructure; finally, it will endow network communication terminals with financial attributes, linking them directly to the blockchain account system, naturally supporting financial functions.

With this new protocol stack, the way we access the internet will change significantly: users will open their browsers, enter ENS domain names, and the browser will resolve the corresponding address through the blockchain and initiate a connection request. Before establishing the connection, the system will verify the identities of both parties through digital signatures from the terminals and a blockchain-based DID system. During this process, all data will be processed through a vast physical routing system, ensuring data is transmitted from one end to the other. When it comes to payments, since the communication terminals have financial attributes, users can pay directly to the ENS corresponding wallet address, avoiding the risk of phishing scams and ensuring payment security and reliability. Whether for social networking, e-commerce, or other applications, the security and decentralization characteristics of the network and transport layers will be inherited.

Next, we will detail how to implement these decentralized features at the network layer, transport layer, application layer, and physical layer.

Network Layer

The design of the network layer must meet four core requirements: First, IP addresses must be sufficient, ensuring that the regional coding of addresses is fairly distributed globally; second, IP addresses need to have financial attributes, allowing direct association with blockchain accounts; third, maintain compatibility with IPv4/IPv6 until a complete transition to the Web3 network; fourth, ensure the decentralization of domain name resolution. To this end, we establish two main types of addresses: unicast addresses and anycast addresses. Among them:

  • Unicast Address: Has unique determinacy, composed of several IDs such as network segment ID, subnet ID, host ID, and network card ID, which can uniquely identify a network card device in the network. Quick routing is based on the ID prefixes of the network segment and subnet to reduce the complexity of the routing table.
  • Anycast Address: Corresponds to wallet addresses and can bind multiple unicast addresses to achieve efficient data transmission. This design not only optimizes the routing efficiency of the network but also significantly increases the supply capacity of IP addresses. When the sender initiates a connection request to the anycast address, the router will send the data packet to the nearest unicast address bound to that anycast address based on routing distance. Since all services provided by the unicast addresses bound to that anycast address are the same, the sender can meet their communication needs by communicating with any one of the unicast addresses.

Unicast addresses achieve quick routing through address prefixes, and their length can be designed to exceed 160 bits of wallet addresses, theoretically allowing for unlimited supply. Anycast addresses are equivalent to wallet addresses, giving financial attributes to IP addresses.

So how can unicast address allocation be achieved in a decentralized manner? In the Web2 era, IP addresses were allocated by centralized institutions. In Web3, these addresses are allocated through smart contracts. Smart contracts generate various network segment ID License NFTs based on network scale, authorizing operators to manage specific subnets. Operators holding network segment IDs can subdivide subnets and sell them to lower-level operators or end users. Operators can run router nodes to handle data traffic, generate profits, and ensure fair and decentralized allocation of IP addresses.

Domain name resolution - the DNS protocol, although defined at the application layer in Web3, logically resembles a protocol for naming network transmission terminals at the network layer. Here, we consider it as a network layer protocol that can be reused by other application layer protocols. DNS in Web3 should be an on-chain resolution protocol, implemented similarly to ENS, where on-chain contracts define the correspondence between domain names and wallet addresses, thus eliminating dependence on centralized entities and avoiding DNS pollution issues.

To ensure that the network can operate normally before full-scale deployment and to solve the cold start problem, we need to make the network compatible with existing IPv4/IPv6. When a router cannot find the target address in its directly connected network, it will encapsulate the data into IPv4/IPv6 packets and send them to routers in other subnets. The receiving router will parse these packets and continue routing within the subnet until the target address is found. This process is similar to the early stages of IPv6 achieving compatibility through tunneling over IPv4 networks.

Additionally, routers are responsible for penetrating internal networks. When data needs to enter an internal network through an IPv4 gateway, public network routing devices will forward these connections. These devices act as reverse proxies for the internal network, allowing data to safely enter internal addresses through tunnels.

To achieve these network layer transformations, corresponding improvements must be made at the physical and transport layers. The physical layer needs sufficient router devices while incentivizing end users, fiber service providers, or current ISP operators to procure these devices to create network effects and gradually replace existing IP networks. At the transport layer, we need further improvements to verify the binding relationship between anycast and unicast addresses and ensure the security and non-repudiation of communications.

Transport Layer

The transport layer ensures the secure transmission of data while eliminating trust in CAs, removing the need for any centralized organization in the security certification process.

Typically, ensuring the security of internet connections (such as websites using HTTPS) relies on SSL/TLS protocols, which depend on CA organizations to verify the authenticity of the accessed website. We hope to use on-chain DID documents to maintain security while eliminating dependence on centralized entities.

This mutual authentication process is executed by accessing the on-chain DID documents. Since both parties' anycast addresses are already registered on the blockchain and linked to their wallet addresses, traditional DNS services required by CAs are no longer necessary. Once the DID documents and wallet addresses are found and associated, and the communicating parties provide valid signatures, it can be confirmed that you are communicating with the legitimate owner of that identifier.

In this way, a wallet-to-wallet connection is established, allowing convenient data transmission through sockets. Similar to how SSL/TLS operates in specific socket environments, this system provides a new option for these connections.

Socket Example

We have proposed several methods for reconstructing the network and transport layers, and the following socket code is an example. Each layer addresses its specific challenges. On this basis, because wallet addresses have financial functions—something ordinary IP addresses do not possess—we can establish connections using socket code and then send transaction instructions through it.

Thus, this new TCP/IP technology stack integrates the characteristics of SSL/TLS, IP routing, and financial transactions. Below is a brief example code.

Application Layer

There are many application layer protocols in the TCP/IP protocol stack, with common ones including HTTP(S), XMPP, SMTP, POP3, FTP, SIP, RTMP, CDN, etc. These protocols traditionally rely on centralized servers, such as XMPP's instant messaging servers and SMTP's mail servers. However, in the Web3 era, decentralized network nodes will replace traditional central servers, and application layer protocols will no longer concern themselves with the servers of applications. These protocols, in addition to defining packet formats above the transport/network layers, will be built on the decentralized network infrastructure of the network layer, allowing the network layer to provide a solid decentralized network foundation for various applications.

Among all application layer protocols, HTTPS, XMPP, SMTP, etc., are the most common, forming the basis of our daily social activities. Under the Web3 architecture, we have developed the first application example using a protocol similar to XMPP—a decentralized instant messaging social application protocol. In this protocol, users utilize their wallet addresses as social accounts, enabling end-to-end encrypted chats, creating private or public chat groups, sending voice and video messages, and even conducting audio and video calls. All of these reuse the secure communication capabilities of the transport layer and the extensive node network of the network layer, using wallet addresses as new network identity identifiers.

In addition to the instant messaging protocol similar to XMPP that we provide, there are numerous application scenarios at the application layer, such as:

  • Web applications based on HTTP and HTTPS: Developers can easily deploy websites on networks based on wallet addresses/ENS domain names, enjoying high-speed access provided by bandwidth sharing from the network while ensuring the application's censorship resistance and secure access.
  • SMTP/POP3 and other email applications: Relying on this network, decentralized email systems will become effortless. When you need to send an email to an ENS domain owner, your application only needs to address the corresponding ENS address node through the network layer, upload the email, and the recipient can download the email from the node.
  • Applications of CDN resource distribution protocols: Relying on this network, developers can distribute their data to various router devices or data center nodes, leveraging a vast node network built on incentive mechanisms, allowing nodes to be spread across the globe, reaching every household. The extensive node network enables the CDN protocol to efficiently utilize idle bandwidth resources, providing developers and users with a faster application experience.
  • Applications of streaming media protocols like SIP/RTMP/WebRTC: With extensive node resources and idle bandwidth sharing, streaming media applications can achieve distributed storage of streaming media content and cache accelerated access, improving the speed and smoothness of streaming media access.
  • Applications of file transfer and access protocols like FTP: Through a vast node network, combined with Web3 decentralized storage projects, the network can actively cache content resources from projects like IPFS/Arweave, accelerating frequently accessed content and enhancing project activity and application scope.
  • Applications of VPN protocols like OpenVPN: VPN applications can reasonably utilize the IP resources shared by routing devices, significantly expanding the range of IP resources for the application, providing the most basic IP and bandwidth resources for VPNs.
  • Message queue protocols like Kafka and RabbitMQ: Message queues are widely used in distributed and clustered applications, with many applications requiring them to facilitate communication between application modules or processes. In the Web3 era, these applications can rely on the extensive node network, using these nodes as natural message queue carriers, providing shared and high-speed message queue services for a wide range of applications.

Physical Layer

The core idea of the physical layer is to promote decentralized routers through incentive measures, leading to widespread adoption in households and ultimately generating network effects. These routers enable users to utilize idle household bandwidth to enhance overall network capacity. By integrating with our network layer protocol, these devices enhance data caching and acceleration functions, benefiting decentralized applications within the ecosystem. These devices optimize bandwidth usage and allow users to earn rewards from their bandwidth contributions.

In the initial phase, we can establish transmission links directly to communication terminals based on the IPv4 architecture through IPv4 tunnels. As nodes become more widespread, we will further attract more fiber service providers through incentives to achieve full interconnection of our hardware network at the physical layer.

Conclusion

The impact of reconstructing the TCP/IP protocol stack will extend far beyond technical changes. By directly integrating wallet address-based routing, domain name resolution, and identity verification into the core protocols of the internet, we are actively building the foundation for a decentralized network. With decentralized instant messaging communication as our initial application layer protocol, a decentralized ecosystem that integrates messaging, financial transactions, and digital asset management is expected to form in the future. This transformation is anticipated to significantly enhance online privacy, security, and freedom, marking a key step towards achieving an open internet.

As mentioned earlier, SendingNetwork has launched a decentralized messaging protocol as the first application layer protocol of our decentralized protocol stack. Users can send end-to-end encrypted messages using wallet addresses, participate in private or public chats, and conduct voice and video calls. The network consists of the following three roles:

  • Edge Nodes: Responsible for forwarding and relaying messages and submitting proof of work.
  • WatchDog Nodes: Send random challenge messages to Edge nodes to check their operational status.
  • Guardian Nodes: Verify the proof of work of Edge nodes and assess their service quality, such as stability, based on the challenges from WatchDog.

The network employs Proof of Relay as the proof of work for message relaying and utilizes Proof of Availability to evaluate node service quality. We have currently opened the first phase of the test network, where Edge nodes can earn points through message forwarding. Next, we will gradually introduce WatchDog and Guardian roles into the network to ensure stable operation in a decentralized environment.

We invite developers and users to join this messaging network, helping Web3 users achieve interconnectivity across different applications through this cross-platform protocol. At the same time, we also invite more like-minded friends to join us in witnessing the transformation of TCP/IP, truly realizing the interconnectivity of the Web3 ecosystem, and co-creating a safer, more private, and decentralized network world, reshaping the future of digital communication infrastructure.

ChainCatcher reminds readers to view blockchain rationally, enhance risk awareness, and be cautious of various virtual token issuances and speculations. All content on this site is solely market information or related party opinions, and does not constitute any form of investment advice. If you find sensitive information in the content, please click "Report", and we will handle it promptly.
banner
ChainCatcher Building the Web3 world with innovators