$\"\"$

(..) it is said that \u22ee\u22ee\u22eeGRIDNET\u00a0<\/span><\/span><\/strong>OS<\/span> materialized from the Old Wizards<\/strong><\/em><\/span>‘\ud83e\uddd9 Pipe Dreams (..)<\/p><\/div>\n

(..) and Fake It Till You make it (..) wouldn\u2019t you?<\/em>\u00a0<\/span><\/p>\n

Right, so what\u2019s the rationale? Why did our beloved Wizards<\/strong><\/span><\/em>\u00a0 come up with these? Let\u2019s highlight the end-result possibilities first.<\/p>\n

\u22ee\u22ee\u22eeGRIDNET\u00a0<\/span><\/strong>OS<\/strong><\/span> allows for multiple UI-based applications to be run simultaneously.<\/p>\n

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.\u00a0\u00a0More!<\/em><\/strong>\u00a0One may access the system through a command-line based interface if he or she\u00a0<\/em>\u00a0feels <\/em>like doing so over SSH.<\/p>\n

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 \u2018think<\/em>\u2019 about the realm of network connections and other details, as it\u2019s all taken care of by the \u22ee\u22ee\u22ee\u00a0<\/span>System<\/span><\/strong> (i.e. through what we call the VM Context<\/strong><\/span><\/em>, an almost(?) magical kind of a thing running right within of a web-browser).<\/p>\n

Now, gaining access, playing around, invoking commands and having a nice front-end UI might be one thing<\/em>.<\/p>\n

Propagating changes to the decentralized network of computers is a whole yet another <\/em>kind of a story.<\/p>\n

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.<\/p>\n

Can bitcoin do this?\u00a0 Certainly not (..) Ethereum?\u00a0\u00a0No way.<\/em><\/strong><\/p>\n

$\"\"$
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.<\/p><\/div>\n
<\/p>\n
Wizards’\u00a0<\/strong><\/span><\/em>\u00a0rant in 3..2..1: Yeah\u2026 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\u2019ve all heard of it.<\/p>\n
Even though the expectations of the most of us were never met, at least Ethereum turned out to be a very usable product<\/em><\/strong>. 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<\/em> \ud83e\udd21 (Irresponsible Ones Taka Advantage, as its name suggests). \u00a0Folks such as those at IOTA are dangerous<\/em> 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\u2026 you know how it is. Everyone needs to eat(..) Anyways ~~ Watch out. That\u2019s what Wizards\u00a0<\/strong><\/span><\/em>\u00a0throw their \ud83e\udd5a at.<\/p>\n
Alright, let us now focus on the Decentralized Processing Threads<\/strong><\/em><\/span>, the subject we\u2019ve got at hand. How do these differ from their centralized corresponding representatives?<\/p>\n
$\"\"$
(..) of yes Investors (..) you listen-up as well<\/p><\/div>\n
\n
For starters, Decentralized Threads<\/strong><\/em><\/span> are so much<\/em> slower<\/strong> 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).<\/li>\n
Yet! These can be<\/em><\/strong> so much more usable, interactive and agile<\/em><\/strong> than what you know from the Ethereum\u2019s 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.<\/li>\n
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.<\/li>\n
The system constantly keeps track of ERG<\/strong> <\/span><\/em>usage while to app keeps running in SandBox. And proposes an optimal value when changes are to be committed.<\/li>\n
This time, some of the operations are to be affecting the decentralized state machine. It\u2019s a decentralized<\/em><\/strong> operating system, <\/em><\/strong>remember?<\/li>\n
It\u2019s no more only<\/em> 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\u2019s volatile memory or storage.<\/li>\n
A thread executes #GridScript<\/em><\/strong><\/span> byte-code<\/li>\n
A thread can contain execute and return results of arbitrary code as needed.<\/li>\n
When it comes to code that is to be committed though, it is to contain only <\/em><\/strong>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.<\/li>\n
Execution of each instruction entails cost. That is very similar to Gas known from the Ethereum\u2019s 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.<\/li>\n
A decentralized processing thread can be spawned on any node maintaining the decentralized \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span>\u00a0<\/span><\/strong>\u00a0state machine and accessed remotely.<\/li>\n
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.<\/li>\n
A single UI dApp can request multiple threads from multiple computers around the world<\/li>\n
Every user session (remote UI session or Terminal) has at least a single thread\u2013the System Thread.<\/li>\n
Every other thread is an offspring of the System Thread.<\/li>\n
The System Thread manages the lifetime of all of its sub-threads.<\/li>\n
Decentralized Processing Threads can be (committed<\/em><\/strong>\u00a0) either separately or in bulk.<\/li>\n
Even though threads can be spawned at multiple computers around the world, they can be also synchronized and committed together all at once.<\/li>\n
A thread can be marked as \u2018committable\u2019 anytime.<\/li>\n
Commitment of the System-Thread causes all of its sub-threads to be committed as well.<\/li>\n
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 \u22ee\u22ee\u22ee<\/span><\/strong>Code Package<\/em><\/strong><\/span>, which is broadcast throughout the network.<\/li>\n
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.<\/li>\n
Threads can be committable or not. A non-committable thread may be useful when only a sandbox execution of commands is desired. It\u2019s important to let the system know about the nature of a thread to prevent it from undertaking some automated measures upon it. \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span><\/span><\/strong>\u00a0is a lot about the end-user\u2019s experience, thus we\u2019ve 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\u2019s dealing with.<\/li>\n
A thread may be a read-only thread. \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span>\u00a0<\/span><\/strong>allows access to such a thread even if a commitment operation is pending.<\/li>\n<\/ul>\n
Above we\u2019ve tackled a few key-concepts, we\u2019ll now go through one by one<\/p>\n
Programmer vs User<\/strong><\/span><\/h1>\n
Programs written for \u22ee\u22ee\u22eeGRIDNET\u00a0<\/span><\/strong>OS<\/strong><\/span> are a mixture of both JavaScript, CSS and #GridScript<\/strong><\/span>. 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 \u22ee\u22ee\u22eeGRIDNET\u00a0<\/span>OS<\/span><\/strong>\u2019 VM Context<\/strong><\/span>. The JavaScript-based VM Context is part of the operating system and is involved in magnitude of things.<\/p>\n
\n
Networking (onion routing across full-nodes, mobile devices, data routing across web-browsers, participates in signalling across all of these).<\/li>\n
Session management. The VM Context<\/span><\/strong> itself is deemed as not trusted<\/em><\/strong> from the perspective of both full-nodes and \u22ee\u22ee\u22eeGRIDNET\u00a0<\/span><\/strong>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<\/strong><\/span> 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<\/strong><\/span> and Kernel Mode<\/strong><\/span>.<\/li>\n
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.<\/li>\n<\/ul>\n
$\"\"$
Extrinsics vs \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span><\/span><\/strong>‘ User Mode and Kernel Mode<\/p><\/div>\n
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\u2019s mobile app? Onion routed? Not knowing its address, not knowing through whom to deliver? No problem at all ~ just tell it what\u2019s to be delivered and the VM Context<\/strong> <\/span>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.<\/span><\/p>\n
$\"\"$
That doesn’t mean that Wizards\u00a0<\/strong><\/span><\/em>do not eat ;d<\/p><\/div>\n
The \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span>\u00a0<\/span><\/strong>terminal is actually a #GridScript<\/em><\/strong><\/span> interpreter. Thus, whenever issuing commands to the console you might already feel like a programmer.\u00a0 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.<\/p>\n
The System-Thread vs Sub-Threads<\/strong><\/span><\/h1>\n
Once user establishes a session with any of the available full-nodes, the node spawns a single instance of a \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span><\/span><\/strong>\u2019 VM<\/strong><\/span> sandbox environment, encapsulating at least a single decentralized thread\u2013the System Thread. <\/span><\/p>\n
Programmer\/user may spawn a new thread anytime by issuing the Start Thread (\u2018st\u2019) command from the #GridScript<\/strong> <\/span>interpreter. When dealing with the \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span><\/span><\/strong>\u00a0JavaScript context (available to UI dApps running from within of a web-browser), a new thread can also be requested\u00a0 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<\/strong><\/span><\/em> instructions directly from within.<\/span><\/p>\n
The concept of Transactions and Code Packages<\/strong><\/span><\/h1>\n
$\"\"$
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 \ud83d\udc7b<\/p><\/div>\n
Some of you might be aware of the nomenclature of transactions from the database-realm. Here, the concept and mechanics are similar.<\/span><\/p>\n
In \u22ee\u22ee\u22eeGRIDNET\u00a0OS<\/span><\/span><\/strong>, \u2018transactions\u2019 have little to do with their simplistic counterparts known from the bitcoin\u2019s realm. It is way more suitable to think in terms of committable \u22ee\u22ee\u22ee<\/span><\/strong>Code Packages<\/i><\/strong><\/span>. Single code package may contain byte-code resulting from compilation of multiple threads living at various nodes. It is thus the \u22ee\u22ee\u22eeGRIDNET\u00a0<\/span>Operating System<\/span><\/strong> 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.<\/span><\/p>\n
Commitment of Threads<\/strong><\/span><\/h1>\n
The \u22ee\u22ee\u22ee<\/span><\/strong>System Thread<\/i><\/strong> <\/span>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 \u22ee\u22ee\u22ee<\/strong>Code Package<\/i><\/strong><\/span> for consideration across the network. Threads and processes can be listed anytime by issuing the Linux-compatible \u2018ps\u2019 command. Processes can be killed by using the \u2018kill\u2019 user-mode command.<\/span><\/p>\n
Let us now take a look at the Terminal UI dApp below.<\/p>\n
$\"\"$
Multiple Threads for same UI session and same UI dApp. Each instance of the Terminal UI dApp has access to a private Thread.<\/p><\/div>\n
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\u00a0\u00a0\u00a0\u22ee\u22ee\u22ee<\/span>VM Context.<\/span><\/strong><\/p>\n
Above, at the upper corner, a mouse-hovered \u22ee\u22ee\u22ee<\/strong>Magic Button<\/span> can be seen. Once, hovered, the \u22ee\u22ee\u22ee<\/span><\/strong>Magic Button<\/span> displays the currently pending actions.<\/p>\n
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<\/em>.<\/p>\n
Notice packages\u2019 names and processes\u2019 IDs next to actions’ descriptions. All it now takes, is for the user to either click or tap the \u22ee\u22ee\u22ee<\/span><\/strong>Magic Button<\/em><\/strong><\/span>.<\/p>\n
Once clicked, the \u22ee\u22ee\u22ee<\/span>VM Context<\/span>\u00a0<\/strong>(running within a web-browser) would instruct the System Thread<\/span><\/strong>\u00a0(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.<\/p>\n
In the background that would be happening by having the\u00a0<\/span>\u22ee\u22ee\u22eeVM Context<\/span>\u00a0<\/strong>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<\/strong>, once executed<\/em><\/p>\n
Note that in the background this might be happening over computers located at different parts of the world.\u00a0 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\u00a0\u22ee\u22ee\u22ee<\/span>Code Package<\/span><\/strong> and (..) instruct the \u22ee\u22ee\u22ee<\/span>VM Context<\/span>\u00a0<\/strong> running within the user’s web-browser to display a QR-Code requesting a signature form the user.<\/p>\n
A nicely animated \u22ee\u22ee\u22eeQR Intent\u00a0<\/span><\/strong>would be shown full-screen, to be scanned by the \u22ee\u22ee\u22eeGRIDNET<\/span>\u00a0Token<\/span><\/strong> mobile app.<\/p>\n
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.<\/p>\n
The system thread would keep notifying both the Web-UI and the mobile app upon the status of processing. If everything looks fine, the\u22ee\u22ee\u22ee<\/span>Code Package<\/span><\/strong>\u00a0 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.<\/p>\n
The below is what occurs from the perspective of the overall operating system. (yes you get to use the magical magnifier yet again!)<\/p>\n
<\/p>\n
$\"\"$
Top level overview on the Threads’ commit process.<\/p><\/div>\n
<\/p>\n
On the other hand, the UML diagram<\/strong> <\/span>below illustrates how the process looks like from the perspective of an UI dApp.<\/p>\n
<\/p>\n
$\"\"$
Decentralized Threads from the perspective of an UI dApp.<\/p><\/div>\n
As you may see above the key thing is assuring synchronization. We don\u2019t want threads committed when not ready (ex. during unfinished partial code formulation etc).<\/p>\n
From the perspective of an UI dApp, performing commits can be either:<\/p>\n
\n
App invoked<\/span> <\/strong>\u2013 that\u2019s when the app wants to have code committed to the decentralized state-machine<\/li>\n
User invoked<\/strong> <\/span>\u2013 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 \u2018rt\u2019 command by hand as seen below:<\/li>\n<\/ul>\n
$\"\"$
Threads being marked as committable.<\/p><\/div>\n
<\/p>\n
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 \u22ee\u22ee\u22eeMagic Button<\/span><\/strong>, which by default commits all of the sub-threads attached to the \u22ee\u22ee\u22eeSystem Thread<\/strong><\/span> i.e. all of its off springs.<\/p>\n
<\/p>\n
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!<\/p>\n
Should you have questions of any sort, shoot right away (..) Twitter, Discords, wizards@gridnet.org ~~that’s where we’re at.<\/p>\n
More on the way!<\/p>\n
~~Forever Yours<\/p>\n
Wizards<\/strong><\/span><\/em>\ud83e\uddd9 \ud83e\uddd9\u200d\u2640\ufe0f<\/p>\n","protected":false},"excerpt":{"rendered":"
Disclaimer: This article is not a scientific one. Still, it targets both IT folks and regular crypto-aficionados alike through a playful mixture…<\/p>\n","protected":false},"author":1,"featured_media":669,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12,9,10,8,13,1],"tags":[],"class_list":["post-619","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-core","category-general","category-os-news","category-news","category-opinions","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/619","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/comments?post=619"}],"version-history":[{"count":79,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/619\/revisions"}],"predecessor-version":[{"id":4805,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/posts\/619\/revisions\/4805"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/media\/669"}],"wp:attachment":[{"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/media?parent=619"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/categories?post=619"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mag.gridnet.org\/index.php\/wp-json\/wp\/v2\/tags?post=619"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}