GRIDNET Core version 1.0.7

[vega4]

Download URL: https://gridnet.org/GRIDNETCore.zip

Release Notes:
Hey folks! What’s up! This was supposed to be Release Notes of version 1.0.6 so why 1.0.7 all of the sudden, huh? Testing, testing, hot-patching… things move around rather fast around here… anyway! Let us go, let us flow (…) the glory of Decentralization it awaits! So, let us take a look (…)

Lots and lots of changes and improvements (yet again…)

• the JavaScript-based ⋮⋮⋮ Decentralized Boot-Loader received a huge revamp.

We’ve actually added a brand new (now acting as initial) stage which verifiers all the nodes which are being discovered through our variance of Kademlia decentralized ⋮⋮⋮ Peers’ Discovery Protocol.

The number of validated data-sources is updated on screen as these are verified:

Feel free to switch to the more detailed Developer’s Pane of Chromium (CTRL+SHIFT+I) to see these validations taking place in much more detail:

Why was that needed? Well, our network is now fully decentralized.

With that said, we have no control over ⋮⋮⋮ Nodes operated by others. As ⋮⋮⋮ Nodes are discovered, these are injected to ⋮⋮⋮ Node’s JavaScript-based Bootloader, which up until now were unable to verify whether the actual assets were reachable and blindly attempted to fetch the assets.

Now the question is - why the assets would not be reachable in the first place?

Simple. Nodes might be behind a variety of NATs / firewalls which, when not properly configured, might thwart access to resources. Also, resources might not be available from a particular node due to invalid TLS certificates and a variety of custom settings imposed by a particular web-browser and/or client’s Internet Service Provider.

So, the bottom line is - now ⋮⋮⋮ Bootloader, verifies and validates access to assets from each discovered peer before assuming it as an appropriate data-source. That immensely improved reliability of the ⋮⋮⋮ Decentralized User Interface Loading mechanics.

There’s more…

• improved protection against network eclipsing attacks

Now, each node will attempt to keep a connection with at least one of the ‘official’ nodes to improve resilience against malicious nodes and network eclipsing attacks. These connections and or data from these nodes are not prioritized in any way.

• yet again - improved performance of synchronization (lots of changes here)

As we’ve already mentioned on Twitter, we’ve been improving synchronization performance for when the history of events of the ⋮⋮⋮ Decentralized State-Machine grows.

What’s so special about the cases at large block heights?

The exchanged ‘chain-proofs’ (proving the history of events, without nodes needing to download the actual data-blocks) between ⋮⋮⋮ Nodes used to get bigger and bigger. Not only did it impose excessive network-overheads, but the processing power needed to analyze these by recipients grew linearly with a given block height of the current leading block.

That processing used to take place within a thread responsible for a given conversation, which could lead to connections being dropped, as not even keep-alive signals were to be exchanged as the recipient verified a provided chain-proof.

So we went ahead and optimized this a lot.

The exchanged chain-proofs are now very minimal. And both the processing power and network overheads are orders of magnitude smaller. Not only that. We’ve also introduced protection against evil nodes which would attempt to enforce processing of large chain-proofs onto others.

• added an additional REST service to GRIDNET Core which would provide information regarding current status of each particular node to the JavaScript-based bootloader.

• improved connections’ management. We test everything 24/7 when anything goes wrong we jump straight into the action and fix things. The overall stability of connections between nodes has been yet again improved.

• improved reporting and logging

• security improvements

• yet again minimized mutex-congestion, leading to better overall performance

• other minor changes

• improved support of internal DNS mechanics by the ⋮⋮⋮ Bootloader:
  
  or it’s probably even better visible below:
  

  

Chromium requires content served by TLS certificates to be accessed from computers pointed to by the Centralized global DNS system (at least in its default configuration), thus we make our internal DNS system translate IPs to known domains. We’ll be making utilities and commands available which would allow for you to register decentralized domains of your own, for now - should you wish to have a node registered within our own domain at *.GRIDNET.ORG simply do let us know and we would issue a certificate and a sub-domain so that you could use it ex. ‘orion.gridnet.org’ or whatever you come up with.

[CodesInChaos]

OK; so at the Poznan University of Technology, we’ve carried out extensive tests of GRIDNET Core 1.0.7, while focusing on the ⋮⋮⋮ Decentralized Bootloader.

We brought up dozens of ⋮⋮⋮ Nodes, while testing using default configuration of Google Chrome.

By default, and as already mentioned by @vega4, Chrome does not accept:

• self-signed certificates - and each ⋮⋮⋮ Node autonomously generates a self-signed certificate, so that others could connect to it from a web-browser. While it is possible to override Chromium’s warning when accessing assets through the address bar, it does not seem to be possible when accessing assets from other nodes, then the one specified within the address bar (ex. through AJAX data queries). Chromium would not allow.

• under any condition, Chromium would NOT at least warn/complain about a certificate which is not issued to a domain registered on the global, centralized DNS system (i.e. in the case of a website not accessed through a domain-name, but through an IP address directly) that holds especially true for AJAX requests. CORS settings of a domain do not matter.

In practice, current implementation of Google Chrome imposes usage of the centralized, global public domain system. It is enforced onto the users. That’s how it is.

In any case, our system remains resilient to that fact, through employment of the ⋮⋮⋮ Decentralized Bootloader, as per its current implemenration, and through the internal Domain Name translation system.

As we’ve tested, the system successfully detects and does not attempt to use ⋮⋮⋮ Nodes who exhibit issues with certificates and/or eclipsed for whatever the reason.

The internal domain-name system is used to translate IP addresses to their corresponding domain-names when one is known. Thus the internal domain-name sub-system acts as a reverse DNS.

This can be seen on the screenshot below:

Notice how IP addresses are translated to their corresponding domain-names on the fly, after which connectivity is tested.

Then, one may notice Chromium complaining about self-signed certificates advertised by some of the nodes. Such nodes would not be used (thanks Google).

In any case, 4 nodes have passed tests and are to be used throughout the bootstrapping process.

Had we wanted to force Chromium to kindly allow us to connect with nodes offering self-signed certificates (on a side-node, that that not inflict any kind of security risks!) we would need to provide Chromium with the following command-line parameter:

–ignore-certificate-errors

You may see how to configure this on Microsoft Windows by altering properties of its shortcut, as seen on snippet below:

OK, after having introduced such a change, remember to fully shut-down all instances of chromium and launch it again, through that shortcut.

Now, our ⋮⋮⋮ Decentralized Bootloader managed to discover, validate and maintain connectivity with… 9 nodes. All of these would be used to serve just a single ⋮⋮⋮ Decentralized User Interface session.

This can be seen below:

And now enjoy watching the process as seen in detail from the Chromium’s Developer pane on the video below: