1. What problem are you solving?
Incognito Nodes serve as simple plug-and-play devices so they often sit behind restricted home-networks. Without manual configurations, these nodes cannot talk directly to each other because of firewalls or protocols such as Network Address Translation (NAT). This proposal investigates a number of promising solutions to help alleviate this problem. For the uninitiated, we give a high-level overview of NAT in the paragraphs below.
Each device on the internet has an IP address. This address helps devices find out where others are in the network and connect to them. There’s only one problem: unique IP addresses are limited. This leads to the emergence of protocols like NAT. In simple terms, a router supporting NAT connects to multiple devices at once and gives each of them a unique local IP address. All of these devices can be dialed from other devices on the Internet by referring to the router’s global IP address.
To draw a parallel picture, imagine 2 people (devices) who need to send a letter to each other. On the envelope, they write the address of the receiver (e.g., 325 S. Santa Claus Lane North Pole, Alaska 99705) to tell the postman where to deliver it. When NAT is used, it’s like they’re asking the postman: “please deliver my letter to the house with the red door”. The house with the red door (local IP address) might be unique if we know which street it is on (global IP address). But in this scenario, there is no way to deliver the letter if only the local IP address is given. To make matters worse, in this scenario, the receiver doesn’t know what their address is, and therefore, they cannot give it to the postman or to the sender.
2. What is the solution?
There are multiple established solutions for NAT traversal, all of which are heavily used in industrial products (such as peer-to-peer file sharing and real-time communication). According to our initial research, here are the promising protocols:
- UPnP, NAT-PCP: request router to forward a fixed port for our application
- STUN (hole-punching): reuse the same port for inbound and outbound connections
- TURN: relay data through another (public IP) server
- ICE: sequentially run the above protocols and use the one with the highest performance
These solutions aren’t deployed in any blockchains that we know of. Therefore, this proposal presents a plan to investigate the protocols in these ways:
- Assess if these protocols are suitable for the Incognito blockchain. Will they completely solve the problem of NAT traversal?
- Test these protocols by implementing small samples/demo applications
- Assess the degree of change to the Incognito blockchain codebase if we want to implement them
3. Which solutions do people resort to because this doesn’t exist yet?
Currently, the NAT problem is bypassed by using highway. As they are devices with public global IP, they act as brokers that connect to all nodes and help exchange information between them. As noted in the article above, highway introduces its own problem:
There is a centralized aspect to this design. Highway is currently run by the Core Development Team. We are working on a plan to enable other teams/individuals to run and connect their highways to the Incognito network.
Incognito chain is fully decentralized, but the network topology isn’t, since all data must flow through highways. Therefore, to achieve operational decentralization, the problem of NAT must be solved so that nodes can connect directly to each other.
4. Who are you?
The initial research phase will be performed by engineers from the Incognito Scalability team (@lam). The results will be verified by other engineers and researchers in the same team (@0xkumi, @dungtran).
5. Why do you care?
We take Incognito’s decentralization plan very seriously. Solving this problem would be a big step toward a more decentralized blockchain for everyone. Also, if we pull this off, we will be the first blockchain to solve this problem.
6. What’s your plan? What’s your schedule?
This proposal is the first step toward a peer-to-peer (p2p) network topology for Incognito. There are 3 steps:
- Research and design how to do NAT traversal (this proposal)
- Research and design how to build the p2p network and the broadcast algorithm given that the NAT traversal protocols work (future work)
- Implement NAT traversal and the broadcast algorithm (future work)
This proposal is scheduled for 4 weeks:
- First 3 weeks: write demo and test on different NAT routers for all the above protocols. Deliverables will be demo programs.
- Fourth week: document and design how to implement these protocols into current Incognito codebase. Deliverables will be a document and the design of the NAT traversal solution.
We will fill out the exact dates after this proposal is approved.
7. What’s your budget?
Resource | Cost | Quantity | Monthly Cost |
---|---|---|---|
Incognito Engineer | 1000 PRV | 2 | 1000 PRV |
Total (x 4 weeks) | 2000 PRV |
8. Is there an existing conversation around this idea?
Not that we know of.
9. Is there anything else you would like the community to know?
Any comments/questions are welcome!
Follow-up proposal: Network topology for efficient p2p networking in Incognito