GRIDNET Core version 1.0.3

Download URL:

Release Notes:

This release, as foretold by the end of the Release Notes of the previous one, - is a result of our continues efforts of making GRIDNET Core more and more resilient to NATs and Firewalls,- so often encountered within computer networks.

The basic idea was to allow for connectivity in obstructed networks, with majority of ports being blocked by administrator of the particular network.

So we needed to come up with a way to conceal most of the traffic, at least the traffic responsible for decentralized peers’ discoveries and exchange of data/blocks/transactions behind something that would seem ‘legitimate’ for network administrators and/or the automated network-traffic analysis toolkits.

So, we’ve picked to conceal all such traffic behind port 443.

Why 443 ?

Because that’s the port used by web-browser for opening encrypted websites i.e. 99% of the time.

Had Administrators decided to block port 443 they would be basically cutting their users out of the Internet. And they usually do not want that to happen, do they?

Web-browsers usually employ port 443 in conjunction with the TCP protocol.

We on the other hand employ 443 both for TCP and UDP traffic encapsulated within the IP protocol.


First, UDP allows for what is known as hole punching.
You may read more on it right over here.

Basically it allows for NATs’ traversal, in majority of the cases. We’ve implemented that as well.

Also, UDP is employed by our UDT-based data-exchange sub-system.
UDT can be way more performant than TCP, and is used in top-of-the class data-centers, such as the one employed byt CERN and the particle colliders of theirs. Yes, GRIDNET Core employs very similar technology. Delivered to your personal computers.

But how have we managed to deliver many sub-protocols through the same port?

UDP and TCP are mutually exclusive. That’s first off.

So we can successfully run the embedded web-server on port 443 TCP, while having port 443 UDP open on the very same machine.

Then, we multiplex port 443 over multiple protocols available from GRIDNET Core.

Currently we’ve made the following communication sub-systems available trough port 443:

  • Decentralized UI services

  • Decentralized storage (ex. delivery of NFTs)

  • decentralized peers’ discovery services

  • Decentralized State Machine’s synchronization services (. i.e. blocks and transactions’ propagation).

In the future we would be leaning towards multiplexing of additional protocols through port 443.

Why wouldn’t network administrators block 443 for UDP? After all, web-browsers use TCP over 443, right?
Wrong. HTTP 2.0 being cooked right now, heavily relies on UDP traffic over port 443, just take a look at the implementation of Google’s QUIC protocol… which your Chromium-based web-browser already well supports.

Yeah… so… 443 seems like a solid, future-proof choice.

More details:

As of now, we are having the UDT-subsystem acting as a super-server. It listens for all of the incoming UDP-based traffic. Then, if UDT deems not to be interested in the data-packet, for whatever the reason, it handles the datagram to ‘network-manager’ who propagates the datagram further down our virtual networking stack, for the datagram to arrive at the Kademlia-based peers’ discovery sub-system which also gets to see whether it wants to see it.

We haven’t introduced any additional datagram encapsulation layer for:

  • performance reasons

  • to allow for data-fuzzing-like security testing of the encapsulated networking sub-systems.

Yeah, so the system basically attempts to attack itself. Why so? Particular networking sub-systems get to see and process datagrams of protocols that were never catered for them in the first place.

We need to make sure that neither of the sub-protocol ever blows.

Since a knowledgeable enough attacker could always be preparing encapsulation datagrams that would only be hiding problems away.

For those of you who do not follow, additional encapsulation datagrams would encapsulate datagrams for all of the underlying communication sub-systems with a flag marking the embedded datagram for processing only by a particular sub-system, say Kademlia. That while certainly less error prone, introduces additional processing overheads and has the potential of hiding existing problems away. We cannot afford for the system to blow when encountered by data of any sort.

Also, additional layers of data encapsulation impose additional overheads, even when BER binary encoding employed.

We’ve tested this for quite some time, restarting nodes, making them synchronize from scratch - with good and stable results.

All in all, Operators! Make sure to have port 443 UDP/TCP open on your network.

Let there be peace upon us and let the Glory of Decentralization prevail!

1 Like

What @CodesInChaos quite modestly described is quite a breakthrough concept on the grounds of its own. We rarely see, in crypto scene proper due sophistication and proper delicate choices of underlying technologies. It is yet a whole different thing to see such things as UDT/UDP/TCP protocols mixed together, multiplex, piped together or whatever through custom implementations.

I would got as far as saying that such ‘things’ are nowhere else to be seen, including such projects as Ethereum and / or Bitcoin.