Reconstructing TCP/IP: Building Communication Infrastructure for Web3
Sending Labs is developing a decentralized communication stack to address the centralization issues of the TCP/IP model, enabling direct peer-to-peer communication via wallet addresses and enhancing internet security, privacy, and user control.
What is the TCP/IP Stack?
In the Web2 era, communication, alongside computing and storage, formed the three pillars of the internet infrastructure. The TCP/IP stack, short for Transmission Control Protocol/Internet Protocol stack, was the primary and most widespread communication framework across this landscape, integrating every layer from the physical to the application level. It’s named after two of two key protocols, TCP and IP, but includes others that enable various functionalities required for modern network communication.
This stack is fundamental to the use of the internet, serving as a guideline for how data is transmitted across networks. It provided a universal set of communication standards and frameworks for a myriad of internet applications. Indeed, almost every Web2 application, whether directly or indirectly, relied on the TCP/IP stack, making it the de facto standard for internet communication.
What’s the Challenge?
As the internet has evolved, the TCP/IP stack has begun to show some fundamental problems. These flaws are hidden in our daily use of the internet. For instance, consider two users communicating through a chat app. When User A sends a message to User B, the message is split into multiple packets and transmitted through various servers across the internet.
At the application layer, accessing websites relies on DNS to resolve service IP addresses. If the system is compromised or hijacked, users may be directed to malicious servers, leading to privacy breaches or data tampering.
At the transport layer, communication security depends on SSL/TLS protocols that rely on certificates issued by trusted Certificate Authorities (CAs). It creates a dependency on centralized trust entities and exposes users to significant trust risks, potentially allowing third parties to intercept or tamper with communications if these CAs are compromised or become untrustworthy.
At the network layer, the limited distribution of IP addresses by a few entities results in resource control concentrated in the hands of a few countries and organizations. This centralization could lead to inequitable resource allocation but also makes the entire network architecture vulnerable to control and manipulation.
These problems are rooted in the centralized aspects of the TCP/IP protocols. Mere patchwork fixes on the protocol stack are not enough to fully address these challenges. Sending Labs is developing a decentralized communication stack that will transform the model by supporting direct peer-to-peer communication using wallet addresses, thus restructuring internet infrastructure to enhance security, privacy, and user control.
Redefine the Three Layers
The decentralized version of the TCP/IP stack should have the following key features:
- Unlimited IP Address Supply: Everyone can obtain their own IP address without needing approval from any organization, ensuring that network resources are not controlled by just a few countries or organizations.
- Decentralized Trust at the Transport Layer: Trust authentication should rely on decentralized cryptographic means, such as blockchain, rather than depending on single CAs.
- Decentralized DNS Protocols: Protocols like DNS should move away from reliance on DNS service providers to blockchain registrations.
- Decentralized Physical Infrastructure: Avoid reliance on large centralized internet service providers by incentivizing the public to host their own routers, thus building a decentralized physical infrastructure network.
- Financially-Enabled Communication Endpoints: Network communication endpoints should inherently possess financial attributes, allowing them to link with wallet addresses and naturally equip applications with financial capabilities.
With this new protocol stack, imagine the future process of accessing the internet: You open a browser, enter an ENS domain name in the address bar, and the browser resolves the address via the blockchain, initiating a connection request to the corresponding address. Before establishing a connection, a handshake process occurs where the terminals’ signatures and the blockchain-based Decentralized Identifier (DID) system verify each other. Once confirmed, the connection is established, allowing access to applications hosted on the corresponding network node.
Throughout this process, all data travels through a vast physical routing system, relying on extensive physical routers to find the application endpoints. When making payments, you can directly transfer funds to the corresponding ENS account, without worries about phishing or fraudulent wallet addresses, ensuring secure payment transactions. These applications could range from social networking to e-commerce shopping platforms, all inheriting the security and decentralized characteristics from the network and transport layers.
Next, we will explore how to implement these decentralized features across the network, transport, application, and physical layers.
Network layer
The reconstruction of the network layer will follow four key guidelines:
- Unlimited IP Address Supply: IP addresses should be infinitely available to prevent monopolization of these resources.
- Financial Attributes for IP Addresses: IP addresses in Web3 should inherently have financial properties, enabling them to be linked with blockchain accounts.
- Compatibility with Existing Networks: Before the complete establishment of the network, set up data pass-through channels to the IPv4/IPv6 networks to maintain compatibility with existing networks.
- Decentralized Domain Name Resolution: The system should ensure that DNS operates in a decentralized manner.
Unlimited IP Address Supply
To meet these requirements, the network would use two main types of addresses:
- Unicast Addresses are unique and composed of identifiers like Network Segment ID, Subnet ID, Host ID, and NIC ID, pinpointing a specific network interface card. Network and Subnet IDs act as address prefixes, aiding routers in identifying the network segment and subnet of the target address, thereby streamlining path selection and simplifying routing tables.
- Anycast Addresses are identical with wallet addresses. An anycast address can be linked with multiple unicast addresses. When initiating a connection, routers route data packets to the nearest unicast address, ensuring efficient communication. All services linked to an anycast address must be identical, allowing seamless communication with any linked unicast address.
Unicast addresses allow for rapid routing based on address prefixes and can be designed to exceed 160 bits (wallet address length), effectively making them available in unlimited quantities. Anycast addresses, identical to wallet addresses, give IP addresses financial properties.
Moreover, the unicast address should be distributed in a decentralized manner. Traditionally, IP addresses are assigned by centralized entities, whereas in Web3, the distribution should be handled by smart contracts. These contracts can manage network segments of varying sizes, issuing Network ID NFT Passes to operators who can then operate within that network segment. Operators holding these passes can further divide and sell access to their segments to smaller operators or end users. This system not only ensures a decentralized distribution of IP addresses but also allows operators to generate revenue by managing internet traffic.
Compatibility with Existing Networks
To ensure the network functions properly before it is fully scaled, it must be compatible with IPv4/IPv6 at the bootstrap stage. If a router cannot find an address within its adjacent network, it should encapsulate and route the data via IPv4/IPv6 packets to other subnet routers. After the router at the recipient’s subnet receives the IPv4/IPv6 packets, it parses the original packet and continues routing within its subnet until the packet is delivered to the target address.This process is similar to early-stage IPv6 tunneling, where IPv6 packets are encapsulated within IPv4 packets. It enables the routing between two IPv6 networks over an IPv4 infrastructure to ensure compatibility.
To achieve this, routers are equipped with Network Address Translation (NAT) capabilities. When data needs to cross IPv4 gateways to access private networks, public routing devices act as reverse proxies, allowing data to seamlessly traverse these gateways to reach private addresses.
Decentralized Domain Name Resolution
Domain Name Resolution — DNS protocol, while traditionally defined at the application layer, logically functions more like a network layer protocol that names network endpoints. We consider it a network layer protocol that can be reused by other application layer protocols. In Web3, the resolution should operate on the blockchain, similar to implementations like ENS. It uses smart contracts to map domain names to wallet addresses, reducing reliance on centralized DNS organizations and thereby preventing DNS hijacking and pollution issues.
To implement these network layer transformations, corresponding upgrades in the physical and transport layers are essential. The physical layer must expand its routing device infrastructure to encourage adoption by end-users, fiber service providers, and ISPs, facilitating the gradual replacement of existing IP networks. Additionally, the transport layer requires modifications to verify the mappings between anycast and unicast addresses and authenticate communication parties, ensuring secure and tamper-proof transmissions.
Transport Layer
The primary goal of the reconstructing transport layer is to ensure secure transmission while eliminating dependence on centralized CAs for trust.
Securing internet connections, such as those to HTTPS websites, typically relies on SSL/TLS protocols which depend on CAs to certify the server authenticity. Our system aims to eliminate this dependency by using on-chain DID documents, maintaining security without relying on centralized entities.
At the start of the connection, the socket initiates a handshake to authenticate the identities of the parties involved, using their DID documents stored on the blockchain. Since both parties’ unicast addresses are registered on the blockchain and linked to their anycast (wallet) addresses, traditional DNS services used by CAs are unnecessary due to the blockchain’s secure, verifiable, and immutable registration. Once the DID document is located and a valid signature is provided, it verifies that the entity you are communicating with is the legitimate owner of that identifier.
In this way, a wallet-to-wallet connection is established, facilitated through the socket. Similar to how SSL/TLS operates within a specific socket context, this system introduces an alternative for these connections.
Socket Programming
So far we have proposed some methods to rebuild the network and transport layers, the following socket code serves as an example. Each layer addresses its specific challenges. Building on this foundation, because wallet addresses have financial capabilities — a feature not present in ordinary IP addresses — we can establish connections using socket code and then send transaction instructions through it.
Thus, this new TCP/IP stack incorporates features of SSL/TLS, routing, and crypto transactions. Let’s explore how this changes socket programming with a brief demo code:
import socket
import blockchain_lib as blc
def create_connection(target_wallet_address):
# Set up a new socket
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# Map unicast address to anycast address on the blockchain
anycast_address = blc.map_unicast_to_anycast(unicast_address)
# Connect to the target using this anycast_address
sock.connect((anycast_address, 80))
target_wallet_address = anycast_address
# Use blockchain for a secure handshake
if not blc.perform_handshake(sock, target_wallet_address):
print("Handshake failed. Connection closed.")
sock.close()
return
print("Connected to", target_wallet_address)
return sock
def send_transaction(sock, transaction):
# Send money instructions to the connected address
sock.sendall(transaction.encode('utf-8'))
print("Transaction submitted.")
# Using the new connection method
target_address = "wallet_address"
transaction_data = "SEND 10 TOKENS TO wallet_address"
sock = create_connection(target_address)
if sock:
send_transaction(sock, transaction_data)
sock.close()Application Layer
The TCP/IP stack’s application layer includes numerous protocols such as HTTP(S), XMPP, SMTP, POP3, FTP, SIP, RTMP, CDN, and more. In the Web2 era, these protocols had central hubs such as Instant Messaging (IM) servers for XMPP and email servers for SMTP, requiring trust in application servers. In the new design, centralized systems should be replaced by various network nodes at the network layer, making it unnecessary for application layer protocols to concern themselves with specific application servers. Besides defining data packet formats at the transport/network layers, the entire implementation of the application layer should be based on the decentralized infrastructure of the network layer. This structure enables the network layer to provide a solid, decentralized foundation for all types of applications.
Within these protocols, HTTPS, XMPP, SMTP are some of the most common. XMPP and its variants for instant messaging, along with SMTP for emails, form the backbone of everyday social interactions. We have implemented a messaging protocol similar to XMPP as the first example of a decentralized IM social application protocol. In this application, users use their wallet as their social account, can send end-to-end encrypted messages to any wallet address, establish private group chats or public communities, and send voice and video messages, or even make voice and video calls. All these utilize the secure communication capabilities of the transport layer and the extensive node network of the network layer, also integrating the new IP address — wallet address identification.
Beyond our IM protocol example, let’s consider the possibilities for other applications:
- Web Applications Based on HTTP and HTTPS: Relying on our network platform, web developers can easily deploy their sites within this wallet-address/ENS domain-based network. Developers will benefit from the network’s bandwidth sharing capabilities for faster site access, utilize decentralized node deployment for censorship resistance, and employ the transport layer’s security mechanisms to ensure safe application access.
- Email Applications Using SMTP/POP3: A decentralized email system becomes effortlessly feasible with this network. To send an email to an ENS domain owner, your application simply needs to locate the corresponding ENS address node through the network layer, upload the email, and the recipient can download it from that node when they come online.
- CDN Resource Distribution: Developers can distribute their data across router devices or data center nodes within a vast incentivized node network. This network could potentially extend worldwide, reaching into every household, allowing the CDN protocol to efficiently utilize idle bandwidth resources, enhancing both developer and user experience with higher application speeds.
- Streaming Media Applications Using SIP/RTMP/WebRTC: Utilizing the wide node resources and shared bandwidth, streaming media applications can achieve distributed storage and caching acceleration, enhancing access speed and smoothness.
- File Transfer and Access Protocol Similar to FTP: Leveraging the extensive node network, integration with decentralized storage projects like IPFS/Arweave can enable active caching of content, accelerating access to frequently visited content and significantly boosting decentralized storage projects’ activity and scope.
- VPN Applications like OpenVPN: VPN applications can make efficient use of shared IP resources from routing devices, significantly expanding the application’s IP resource pool and providing fundamental IP and bandwidth resources.
- Message Queue Protocol like Kafka, RabbitMQ: Widely used in both distributed and clustered applications for communication between modules or processes, these applications can rely on the extensive node network, utilizing these nodes as natural message queue carriers, providing shared, high-speed messaging services to a broad range of applications.
Physical Layer
At the physical layer, the core idea is to use incentives to broadly distribute physical routers into homes, thereby generating a network effect. Initially, the network builds on the IPv6/IPv4 framework, enabling endpoint connections through tunnels. As node distribution expands, additional incentives will encourage more fiber service providers to integrate our hardware, leading to a robust physical network connection.
These devices enable users to utilize their idle household bandwidth to improve overall network capacity. By integrating with our network layer protocol, these devices enhance data caching and acceleration, benefiting decentralized applications and similar platforms. These miners optimize bandwidth usage and allow users to earn from their bandwidth contributions.
What’s Next?
Rebuilding the TCP/IP stack extends well beyond technical enhancements. By integrating wallet address-based routing, domain name resolution, and on-chain identity authentication into the core internet protocols, we are actively constructing the foundation for a decentralized network.
As mentioned, SendingNetwork has launched a decentralized messaging protocol, the first application layer of our decentralized protocol stack. Users can send end-to-end encrypted messages, engage in private or public chats, and make voice and video calls using their wallet addresses. The network comprises three key roles:
- Edge Nodes: Responsible for forwarding, relaying messages, and submitting proof of work.
- WatchDog Nodes: Send random challenge messages to Edge Nodes to monitor their uptime and availability.
- Guardian Nodes: Validate the work proofs from Edge Nodes and assess their service quality based on challenges from WatchDog Nodes.
The network utilizes Proof of Relay for validating message relays and Proof of Availability to assess node service quality. The first phase of our testnet is now live, allowing Edge Nodes to earn credits by relaying messages. We will gradually introduce WatchDog and Guardian roles to ensure stable operation in a decentralized environment.
We invite developers and users to join our messaging network, facilitating connectivity across Web3 applications via this cross-platform protocol. We also call on like-minded friends to join us in witnessing the transformation of TCP/IP, fostering a more secure, private, and decentralized online world and reshaping the future infrastructure for digital communication.
For more details, stay tuned to SendingNetwork’s official channels.
