GRIDNET Core version 1.0.9 (Winter Season)

Download URL: here

Version: 1.0.9

Release Notes:

Happy and Profitable ⋮⋮⋮ Winter Season :snowflake: to everyone !

  • we have added support of ‘special’ events to both Core and UI, on the first sight this can be noticed through dynamically chosen wallpapers visible within the ⋮⋮⋮ Decentralized UI.

  • the support of Special Events has now also been added to the ⋮⋮⋮ Decentralized Bootloader. Special content would be fetched only if a given special event is active.

  • there has been an immense amount of stability improvements at various levels.

  • improved detection of when a GPU transitions into a ‘zombie’ state, meaning when it’s supposedly running but not returning any kind of results. In such a case, ⋮⋮⋮ Core would attempt to resuscitate the sleepy GPU and bring it back to order.

  • Improved support of cases when the OpenCL exhausts the entire search space while looking for a ‘nonce’. While we had already well supported such a case in a multi-gpu scenario, with individual GPUs requesting additional search spaces on demand, this has now been improved in a single GPU scenario, also in a multi-case scenario when all GPUs indeed exhaust the entire search space, in which case, the entire Key-Block would be generated anew indeed.

  • lots and lots of improvements to synchronization of the ⋮⋮⋮ Decentralized State Machine.

  • lots and lots of other improvements

Even though the recent Token-Generation event went through just fine, we’ve experienced lots of hiccups during the following events as others joined the network. We’ve continued to collect data, analyzed these and included lots of improvements. Details regarding these were mentioned on Twitter thus we wouldn’t be going much into the details… or we would… but just a little quick as it’s the Season of Fun!

Basically, right after the Token-Generation event, we run into a very rare edge-case scenario, in which one of the chain-proof analysis sub-system would fail to synchronize nodes with the current (external) state advertised by other nodes. Chain-proofs are data-structures which prove validity of the history of events, without a peer needing to download contents of the actual data-blocks (ex. those encapsulating transactions). Recall that recently we have been optimizing these mechanics when operating at large block heights so that the entire chain-proofs, starting from Genesis Block, would not need to be exchanged among the peers. We then went into great lengths with optimizations, making sure that only sub-chain-proofs are exchanged and only as advised by checkpoints - provided by nodes willing to be synchronized. Then we went even further by making sure that others cannot abuse the system and doing yet further optimizations of particular algorithms.

To have an overview of the problematics imagine that node A joins the network, while being aware of block height 1000. To all of its surprise, the decentralized state machine is already at block height 4000 though. Now it needs to synchronize. Certainly we do not want it to be in need of fetching all of the data blocks in between as that might be (4000-3000)* 10MB if the average data-block size turned out to be 10MB. Had it had full confidence in nodes doing data deliveries it might just proceed but… we assume everyone to be a potential attacker. We assume that each and every node might be willing to produce fake data-blocks so to waste processing power and bandwidth of node A.

So before A proceeds into downloading data-blocks from other peers it first requests what we call a chain-proof. The chain-proof is a sequence of block-headers leading, in this example, from block 1000 to block 4000. But hold on a sec… what if node B does not have block at height 1000 available at all? what there had been a fork at block-height say 970 while A wasn’t around? That is why node A provides a sequence hashes representing potential synchronization points to B, before the latter generates a chain-proof. If node B does not find a match with any synchronization point, it would proceed with generating an entire chain-proof starting from the very first Genesis Block and give it to A.

A seeing the chain-proof it would reconstruct the entire chain-proof as known by B, notice - only being provided with the sub-chain-proof by B, by finding a common point and concatenating the two. It would then calculate the total cumulative proof-of-work of the entire resulting chain-proof, and after having done some additional analysis, it would proclaim this very chain-proof as the best known history of events and indeed proceed with downloads, from multiple nodes.

As blocks are being fetched, these are then enqueued to the Blockchain Manager which does analysis on per-block basis. Verified blocks make their way into the Verified history of events. Only the verified history of events is used for presenting the current world-view to others.

And how is the world-view presented? You were right! Through chain-proofs. To be more precise, chain-proofs are used to guide block-downloads ensuring that others cannot trick your node into downloading faked blocks or into presenting your node with a falsified world-view (chain-proofs include proof-of-work of each and every key-block).

We have now improved algorithms related to these, validated everything through meticulous data-fuzzing tests and everything seems 100% stable, which is Great!

As for the ⋮⋮⋮Mining Operations, we’ve continued testing the now improved OpenCL support on dozens of workstations going on and on for 24+hours now, no problems at all. These nodes came with Intel/NVIDIA and AMD GPUs. Some were mining solely using CPUs as well. In all cases, not a single, even minor, trouble was spotted.

Which is to say that we are safe to let the ⋮⋮⋮ Winter Season Celebrations - 2022 Begin❄ !

:snowflake: Winter Season Special Event - Details:
bombkiSame

Important: all the perks and bonuses mentioned below are additional to the standard block rewards and other ⋮⋮⋮ Incentives offered and ensured by the ⋮⋮⋮ Network! Remember to report each ⋮⋮⋮ Winter Task completed on Discord to claim your rewards!

Event Expires: on the 14th of January 2023 (anywhere on Earth).

  • For the very fact that you got your ⋮⋮⋮ Running - you get GNC worth 50 USD

  • For each day your ⋮⋮⋮ Node remains operational - you get GNC worth 25 USD

  • If your node remains accessible from the outside, i.e. offers ⋮⋮⋮ UI services, you would be getting additional GNC worth 10 USD per each day. Note that either a public Ipv4 address or proper NAT configuration would be needed.

  • GNC worth 100 USD if you upload a ⋮⋮⋮ Winter Season related NFT, one you’ve created (that is important!), to the ⋮⋮⋮ Decentralized Storage.

  • GNC worth 100 USD if you create your very first decentralized Website on the ⋮⋮⋮ Decentralized Storage.

  • GNC worth 50 USD if you create and register your ⋮⋮⋮ Identity so that others can send you ⋮⋮⋮ GNC simply by relating to your nickname, or to access your ⋮⋮⋮ Decentralized Website by going to GN://nickname within the ⋮⋮⋮ Anonymous Web-Browser UI dApp.

Now probably the best part:

  • you get 5% of what your friends receive - at each level! For this make sure to report ⋮⋮⋮ Friendly ID of the friend of yours who influenced you in becoming a ⋮⋮⋮ Operator - do so on Discord!

Merry, Happy and Profitable ⋮⋮⋮ Winter Season to everyone !!! ~ towards the Glory of Freedom and Decentralization!