Disclaimer: This article is not a scientific one. Still, it targets both IT folks and regular crypto-aficionados alike through a playful mixture of science, facts and grotesque.

Reading through will give you a solid overview on some of the architectural details the kinds of possibilities and architectural decision to expect from the upcoming production-release.

First off, we’ve prepared for you a simplified UML Use Case diagram involving elements around the ⋮⋮⋮GRIDNET Operating System. It depicts interactions between external actors and some of the internal sub-systems. Swipe your finger over the infographics below to activate the Wizardous zoom/pane which will allow zoom-in on some of the details.

Whenever architectural elements are mentioned it may come in handy.

⋮⋮⋮GRIDNET OS‘ Use Case UML Scheme

Decentralized Processing Threads,- what are these?  Are they for real? Or maybe these are just fancy names pulled out of the Wizards’  magical hats?🎩 ~Propaganda-talk used to shill The Holy Project of theirs so that they could continue on their devious quest (..) towards decentralization of the entire planet(..)?

A Wizard🧙 removing weeds from the ground, that’s a joyous view 🤭

(..) After all, the nomenclature of a ‘decentralized operating system’ in itself might sound to some like one big tasty marketing click-bait  (it certainly would have sounded like so to Wizards  were it not for themselves behind the wheels ).

Marketing is important. There’s no escaping of that.

Still, some choose to make it the sole prominent part of their project. Enter the realm of ..

IOTA:”(..) we’ll incentivize your data exchange we don’t know how (..) now you just give us some $$$ (..)”

(..) and indeed! (..) Nobody shall ever beat IOTA🤡 (Irresponsible Ones Take Advantage) in the arts of deception.

If you feel like it, you may read more about it over here. The topic itself certainly deserves a separate publication at our Holy Mag. Still, this one has nothing to do with data-exchange so we’ll just relax and skip over it. Wizards certainly do not have time to take a shit on other projects (feel free to browse through some of the recent tweets for more), but IOTA🤡 (as the name suggests) at least deserves it. Big Time. And every now and then even a Wizard might come in a need of an urgent thing so..😮‍💨

Alright, listen up, for the aim of this article, first off,- is to provide those of you not familiar with computer science with a quick background check on what traditional ‘threads’ are. Don’t you be afraid ~Here, we won’t be getting into much of a detail as the Internet is full of resources on the matter (Wikipedia).

Second, the point is to give you a solid overview of the coined by us Decentralized Processing Threads. Now, since here is the only place on the Internet to get to know about these, we shall be focusing on the latter, wouldn’t you agree?

Buckle up fellas! Head-starting with traditional ‘centralized’ threads now!  Let the story begin to unfold (..) let the bits and bytes flow (..) the 0s and 1s (..) let them flow all around .

Long time ago.. in a galaxy far away (..)

The Concept Of A Thread

(..) threads’  (..) simple as that, not?

Without threads, you wouldn’t bare it, you wouldn’t take it.

Threads make your life easier each and every day! In short, threads allow for management of concurrency. To understand it, become aware of the fact that the very electronic device of yours, the one you’ve been looking at trying to figure out what Wizards  have been after as of recent included, performed hundreds of thousands of operations in the background. Data has been transmitted between your computer and their server, the screen refreshed thousands of times (and counting), the web-browser kept reacting to gestures and mouse-movements (..) And are you listening to music while reading this?

All these actions are always carried out either directly or indirectly through the Central Processing Unit (CPU). Multiple other peripherals may be involved! The screen, the speakers, the radio transmitter (..) Touch sensor, touchpad, mouse, keyboard, memory units and so on.

The important thing to note is that a CPU executes instructions written by programmers. Those (not-so-always)boring folks make them tick as desired so that the user experience is delivered.

Now, how many simultaneous instructions can a CPU perform? Well, that depends on its architecture . On its number of ‘cores’, to be semi-exact. Indeed, allowing ourselves for some sloppy simplifications, a single core can execute a single instruction at a time. The more cores, the more things going on at a time. The more fun, the more pleasurable the user experience gets to be.

What ‘rules’ the CPU? The ‘Operating System’ . The latter is just a piece of software as well. Why so special? Is it? It manages other programs. At least that’s one of its main purposes.

The operating system employs the convention of threads to create an illusion of multiple applications operating simultaneously, no matter what the number of the underlying hardware CPU cores actually is. An illusion?  Yeah. But if you don’t get to notice, does it matter? No hard feelings about it; it’s only tech.

The bits and bytes (..) the 0s and 1s (..)

The operating system spawns a new thread on the programmer’s request and wraps his code around it. The programmer gets to tell which thread gets which instructions to run. The operating system is aware of each and every thread owned by each and every application. Oh Yes, a single application can own multiple threads . Once an application exits, all of its threads are guaranteed to be terminated as well. The operating system distributes execution time-slots provided by the CPU across all the active threads.

The time-slots assigned to individual threads are so small that you wouldn’t notice. In a way, it’s like watching a movie. You don’t get to see the flickering of individual frames. Our brains don’t react so fast. Our vision system, at least.

2D sprites are in use even today! From the perspective of a being ‘living’ in the 5th dimension, would we just be static 4-dimensional sculptures? The Time would have ceased to exist

A traditional thread has one owner. It is the app . The thread can be managed by both the operating system and the owning app (to a limited extent). The thread’s lifetime never exceeds the app’s lifetime. Threads can be started and killed by the two on demand. Threads are containers for instructions. They have an identifier and can be looked-up and queried by it. Threads allow for more efficient processes’ isolation. Each thread has a stack of its own.

All these properties have a common denominator with what we’re about to show. With some notable differences, though.

(..)  We’re now entering the realm of…

Decentralized Processing Threads 🎩

(..) it is said that ⋮⋮⋮GRIDNET OS materialized from the Old Wizards‘🧙 Pipe Dreams (..)

(..) and Fake It Till You make it (..) wouldn’t you? 

Right, so what’s the rationale? Why did our beloved Wizards  come up with these? Let’s highlight the end-result possibilities first.

⋮⋮⋮GRIDNET OS allows for multiple UI-based applications to be run simultaneously.

One may click or touch through the UI just like if using a regular (i.e. centralized) Windows/Linux and/or Mac-OS X box.  More! One may access the system through a command-line based interface if he or she  feels like doing so over SSH.

One may keep using application A which queries the decentralized VM for data while application B affects the decentralized VM the very same moment as both apps remain fully responsive. In the background both apps can be communicating with the very same or multiple different full-nodes. The UI dApps do not even need to ‘think’ about the realm of network connections and other details, as it’s all taken care of by the ⋮⋮⋮ System (i.e. through what we call the VM Context, an almost(?) magical kind of a thing running right within of a web-browser).

Now, gaining access, playing around, invoking commands and having a nice front-end UI might be one thing.

Propagating changes to the decentralized network of computers is a whole yet another kind of a story.

Talk about interactive code formulation while user(s) interact with the system, synchronizing ad-hoc execution of instructions at full-nodes, maintaining proper state across applications, ensuring state-boundaries (separate stacks), allowing for replication of code execution results across the decentralized network of nodes.

Can bitcoin do this?  Certainly not (..) Ethereum?  No way.

Presumably, nothings nowadays progress as fast as technology. These are the times when currently living people believe in the possibility of being immortal. Come in terms with that. We need to put our believes in technology, in progress and not to create yet another bitcoin-religion. People are now smart enough to respect supply rules alone.

Wizards’  rant in 3..2..1: Yeah… we all used to put our hopes in Ethereum in years when it used to be marketed the most. (..) The decentralized computer of yours (..) as they used to put it (..) you know it (..) we’ve all heard of it.

Even though the expectations of the most of us were never met, at least Ethereum turned out to be a very usable product. It pushed the technology to whole new level. Maybe not as much as ‘bitcoin’. Yet again at least it was not a shill-scam-bubble like IOTA 🤡 (Irresponsible Ones Taka Advantage, as its name suggests).  Folks such as those at IOTA are dangerous since they know their devious ways around the tech well enough to even trick some researchers (..) paying them for travel tickets to conferences, funding food and stuff… you know how it is. Everyone needs to eat(..) Anyways ~~ Watch out. That’s what Wizards  throw their 🥚 at.

Alright, let us now focus on the Decentralized Processing Threads, the subject we’ve got at hand. How do these differ from their centralized corresponding representatives?

(..) of yes Investors (..) you listen-up as well

• For starters, Decentralized Threads are so much slower than their centralized counterparts. All the thumb-rules of projects such as Ethereum apply here as well if code is to be replicated (it does not need to be).
• Yet! These can be so much more usable, interactive and agile than what you know from the Ethereum’s realm! How? They can execute arbitrary code in Sandbox mode while an app is already running without necessarily affecting the decentralized state-machinery i.e. without replicating results across nodes. This allows to offset slow processing at full-nodes with very fast CPUs and GPUs available on users’ local computers.
• In need of some agility? The code can be formulated while an UI dApps keeps running and authenticated at the end (..) by the end, compiled, put within the Code Package and replicated throughout the network.
• The system constantly keeps track of ERG usage while to app keeps running in SandBox. And proposes an optimal value when changes are to be committed.
• This time, some of the operations are to be affecting the decentralized state machine. It’s a decentralized operating system, remember?
• It’s no more only about your local laptop or smartphone. Now things are different. The user-invoked operations, the instructions within the threads, they need to affect computers all over the planet. Not only your local device’s volatile memory or storage.
• A thread executes #GridScript byte-code
• A thread can contain execute and return results of arbitrary code as needed.
• When it comes to code that is to be committed though, it is to contain only instructions that are to affect the decentralized state machine. There is no need for a decentralized thread to contain code responsible for animations, for things that are irrelevant to the decentralized consensus.
• Execution of each instruction entails cost. That is very similar to Gas known from the Ethereum’s realm. Even still, each client is granted a welcoming bonus Erg once he or she connects. The bonus amount can be used only in SandBox mode and cannot be used for code-replication.
• A decentralized processing thread can be spawned on any node maintaining the decentralized ⋮⋮⋮GRIDNET OS  state machine and accessed remotely.
• A single UI session can be taking use of multiple threads at multiple nodes within the network, i.e. each UI app on same remote desktop session, within same UI session, can be spawned on a different computer around the world. One Terminal UI dApp can be running on a computer located in New York while another in Shanghai. These instances can be interacting with each other through Onion-Routed connectivity.
• A single UI dApp can request multiple threads from multiple computers around the world
• Every user session (remote UI session or Terminal) has at least a single thread–the System Thread.
• Every other thread is an offspring of the System Thread.
• The System Thread manages the lifetime of all of its sub-threads.
• Decentralized Processing Threads can be (committed ) either separately or in bulk.
• Even though threads can be spawned at multiple computers around the world, they can be also synchronized and committed together all at once.
• A thread can be marked as ‘committable’ anytime.
• Commitment of the System-Thread causes all of its sub-threads to be committed as well.
• When a thread is committed, all the instructions located within it are compiled on the fly into a byte-code and put within a single ⋮⋮⋮Code Package, which is broadcast throughout the network.
• Threads can be shared (if not marked as private) and indeed threads can have multiple flags. Such nuances are beyond the scope of this article.
• Threads can be committable or not. A non-committable thread may be useful when only a sandbox execution of commands is desired. It’s important to let the system know about the nature of a thread to prevent it from undertaking some automated measures upon it. ⋮⋮⋮GRIDNET OS is a lot about the end-user’s experience, thus we’ve given users the power to invoke various operations (like having all applications committed) with a single key-press. For the OS to handle threads properly, it needs to know what it’s dealing with.
• A thread may be a read-only thread. ⋮⋮⋮GRIDNET OS allows access to such a thread even if a commitment operation is pending.

Above we’ve tackled a few key-concepts, we’ll now go through one by one

Programmer vs User

Programs written for ⋮⋮⋮GRIDNET OS are a mixture of both JavaScript, CSS and #GridScript. The latter is (to large extent) backwards compatible with Forth. It executes on full-nodes while JavaScript code runs within web-browsers. All the user-mode functionalities are made available for in-web-browser applications through what is known as a ⋮⋮⋮GRIDNET OS’ VM Context. The JavaScript-based VM Context is part of the operating system and is involved in magnitude of things.

• Networking (onion routing across full-nodes, mobile devices, data routing across web-browsers, participates in signalling across all of these).
• Session management. The VM Context itself is deemed as not trusted from the perspective of both full-nodes and ⋮⋮⋮GRIDNET Token mobile apps. With that said, it still has the power of ruling and synchronizing applications running within a single user-mode session. The VM Context acts as an intermediary between user-mode UI elements and the kernel-mode eco-system. The decentralized consensus is deemed to be part of kernel mode operandi. Below you may see a simplifies infographics showcasing allowing to grasp differences between User Mode and Kernel Mode.
• Ad-hoc, in-the-background code formulation. This occurs for instance when user performs some UI-related actions that are to affect the decentralized state-machine, like drag-and dropping a file onto a GRIDNET-OS file manager UI dApp , from the host, centralized operating system.

Extrinsics vs ⋮⋮⋮GRIDNET OS‘ User Mode and Kernel Mode

The infographics herein are by no means complete and only touch upon vast topics and APIs pending additional documentation. User Mode API is easy to use. It was designed to allow JavaScript developers to get things done nice and easy. New thread? Sure! Willing to deliver a notification to the user’s mobile app? Onion routed? Not knowing its address, not knowing through whom to deliver? No problem at all ~ just tell it what’s to be delivered and the VM Context would use the data it stored during session-negotiation while the user logged on by scanning the Log-Me-In QR Code. The kernel mode APIs are much more sophisticated and unavailable to User-Mode applications, by default.

That doesn’t mean that Wizards do not eat ;d

The ⋮⋮⋮GRIDNET OS terminal is actually a #GridScript interpreter. Thus, whenever issuing commands to the console you might already feel like a programmer.  From now on the terms of user and programmer will be used interchangeably. And indeed, the language has been designed to accommodate its usage as a command-line user interface and to facilitate ad hoc representation of actions performed within the UI so that the resulting in-code representations of these could be broadcast across the network and affect the decentralized state machine.

The System-Thread vs Sub-Threads

Once user establishes a session with any of the available full-nodes, the node spawns a single instance of a ⋮⋮⋮GRIDNET OS’ VM sandbox environment, encapsulating at least a single decentralized thread–the System Thread.

Programmer/user may spawn a new thread anytime by issuing the Start Thread (‘st’) command from the #GridScript interpreter. When dealing with the ⋮⋮⋮GRIDNET OS JavaScript context (available to UI dApps running from within of a web-browser), a new thread can also be requested  by invoking its createThread() sub-routine. The VM-Context would automatically choose the most suitable node and attempt to use its resources for the purposes of spawning a new thread. Under the hood, the initial full-node, the one handling the connection itself, is always aware of every sub-thread. What are the implications? The system-thread has the ability to affect any of its sub-threads by executing #GridScript instructions directly from within.

The concept of Transactions and Code Packages

Believe it or not, little bit over 10 years ago decentralized ‘transactions’ were only about decrementing value A while incrementing B by the same amount equal to C. That is what Bitcoin used to be about 👻

Some of you might be aware of the nomenclature of transactions from the database-realm. Here, the concept and mechanics are similar.

In ⋮⋮⋮GRIDNET OS, ‘transactions’ have little to do with their simplistic counterparts known from the bitcoin’s realm. It is way more suitable to think in terms of committable ⋮⋮⋮Code Packages. Single code package may contain byte-code resulting from compilation of multiple threads living at various nodes. It is thus the ⋮⋮⋮GRIDNET Operating System assuring that the boundaries between the threads are maintained at all times, and whether the particular threads should be compiled, committed and thus broadcast across the network.

Commitment of Threads

The ⋮⋮⋮System Thread is always aware of all of its sub-threads. When committing threads in bulk it would be the system-thread performing synchronization across all the sub-threads, compiling source codes coming from within of each and committing i.e. broadcasting the resulting ⋮⋮⋮Code Package for consideration across the network. Threads and processes can be listed anytime by issuing the Linux-compatible ‘ps’ command. Processes can be killed by using the ‘kill’ user-mode command.

Let us now take a look at the Terminal UI dApp below.

Multiple Threads for same UI session and same UI dApp. Each instance of the Terminal UI dApp has access to a private Thread.

Back when each of the above UI Terminal dApps was launched, each had requested a brand new decentralized processing thread for the purposes of executing commands input by the user. That was achieved by querying an appropriate method of the   ⋮⋮⋮VM Context.

Above, at the upper corner, a mouse-hovered ⋮⋮⋮Magic Button can be seen. Once, hovered, the ⋮⋮⋮Magic Button displays the currently pending actions.

What does it mean for an action to be pending? That it is yet to affect the decentralized consensus. Currently it shows two applications awaiting to be committed.

Notice packages’ names and processes’ IDs next to actions’ descriptions. All it now takes, is for the user to either click or tap the ⋮⋮⋮Magic Button.

Once clicked, the ⋮⋮⋮VM Context (running within a web-browser) would instruct the System Thread (running at a full-node) to collect source-codes from all of its sub-threads.That would include threads owned by both of the above UI dApps.

In the background that would be happening by having the ⋮⋮⋮VM Context formulate an appropriate BER-encoded VM-Meta-Data processing request, one containing autonomously formulated #GridScript commands, causing the system thread to initiate the code-commit manoeuvre, once executed

Note that in the background this might be happening over computers located at different parts of the world.  Once all the intermediary source-codes, from the corresponding sub-threads have been fetched, the system thread would then compile these, doing some pre-processing assuring proper execution contexts (stack-frames-related), put the resulting byte-code into a single ⋮⋮⋮Code Package and (..) instruct the ⋮⋮⋮VM Context  running within the user’s web-browser to display a QR-Code requesting a signature form the user.

A nicely animated ⋮⋮⋮QR Intent would be shown full-screen, to be scanned by the ⋮⋮⋮GRIDNET Token mobile app.

It’s not the end of the story. The mobile app would be handed the resulting code package, decompile it and generate a meta-data description of things that are to be performed in the name of the user. Upon the user’s consent (after using the Virtual Fingerprint sensor), the private key stored by the mobile app would be used to generate an elliptic curve signature which would be onion-routed to the full-node at which the System-Thread currently resides.

The system thread would keep notifying both the Web-UI and the mobile app upon the status of processing. If everything looks fine, the⋮⋮⋮Code Package  would be broadcast across the network. In fact, the process is much more complicated than that, you may look at the infographics below to gain a more vivid higher-level overview.

The below is what occurs from the perspective of the overall operating system. (yes you get to use the magical magnifier yet again!)

Top level overview on the Threads’ commit process.

On the other hand, the UML diagram below illustrates how the process looks like from the perspective of an UI dApp.

Decentralized Threads from the perspective of an UI dApp.

As you may see above the key thing is assuring synchronization. We don’t want threads committed when not ready (ex. during unfinished partial code formulation etc).

From the perspective of an UI dApp, performing commits can be either:

• App invoked – that’s when the app wants to have code committed to the decentralized state-machine
• User invoked – user may trigger commitment of a thread, but first the thread needs to be marked as committable in the first place. Marking thread as committable is achieved by executing the Thread-Ready command on the particular thread. Note that this can be tested and seen by running the Terminal UI dApp and executing the ‘rt’ command by hand as seen below:

Threads being marked as committable.

Once a tread is marked as committable, the system may commit it anytime. This might be either system-invoked or user-invoked. A sample case of a user invoked global commit would be user tapping the ⋮⋮⋮Magic Button, which by default commits all of the sub-threads attached to the ⋮⋮⋮System Thread i.e. all of its off springs.

That’s it for now fellas! Keep in mind that as complicated as it all might look, lots of details (including architectural ones) were omitted. Certainly data-routing would be such a thing. We’ve implemented very sophisticated onion-routing apparatus to allow for the above to be happening (ex. targeting specific Threads located of separate nodes). That’s a topic which deserves an article of its own . Stay tuned for more soon, we’re polishing the UI/Decentralized Thread mechanics and soon you’ll be able to take the entire Web-UI for a ride yourself!

Should you have questions of any sort, shoot right away (..) Twitter, Discords, wizards@gridnet.org ~~that’s where we’re at.

More on the way!

~~Forever Yours

Wizards🧙 🧙‍♀️