GridScript Basics and Micropayments – From the User’s Perspective

⋮⋮⋮ Today we will be looking at Stateless-Channels, as described within some of our research papers and Multi-Dimensional Token Pools in particular – from the user’s perspective. This is the first article in the series of articles related to the subject. In a way material described here gets ahead of what had been documented in our official research publications. Nevertheless, it has been implemented, found its way into ⋮⋮⋮GRIDNET OS already and does more than great! Some may compare Stateless-Channels to Lightning Network found within the Bitcoin’s realm. Indeed, the comparison would be valid. Under the hood, implementation of State Less Blockchain channels is more ‘streamlined’ than what can be seen within the Lightning Protocol.

We believe this leads to fewer constraints and more use-case flexibility. Not only do we allow for anonymized network, where data is onion routed, we also allow the network to span across web-browsers, giving users and developers access to an extremely convenient JavaScript API.

This could be seen with the crypto-snake game where parties are rewarded without being previously known to any smart-contract and no a priori preparation needs to be take place before an unknown party begins receiving micro-payments.

That’s a thing which is simply not possible within the Lightning Protocol.

The topics described in here have been covered partially already within the Whitepaper.

In this article we will approach things from a practical point of view while having access to the ⋮⋮⋮GRIDNET OS Decentralized Terminal Interface (DTI) and handle ⋮⋮⋮Token mobile app. What a joy! ~The two seem to go along quite well, don’t they? 😁

By reading on you will:

get some hands-on experience with #GridScript basics
you will get to know how to time-travel
learn why on-the-chain transactions are not always good and the ⋮⋮⋮GRIDNET OS solution
get to know how the Snake🐍 game issues rewards
how to cash-out rewards received within the game
check for yourself if double-spends are possible 😄
learn how to create and register Token Pools of your own

#GridScript definitely needs a documentation on its own. You will be glad to know that it is backwards compatible with Forth and there are a lot of places on the Internet to start from! Here may be a good place to get you started. #GridScript is backwards compatible, but it includes A LOT of new extensions, security mechanics, cryptography and decentralized consensus operandi. It includes support of runtime-metadata, type conversions, Java-like memory management, pay-per instruction mechanisms, decentralized applications support and so much more. From your current viewpoint it includes something as essential as in-line parameters which allows the entire #GridScript interpreter to be perceived as a command-line interface.

Indeed, everything you have ever typed so far on ⋮⋮⋮GRIDNET OS, all the Linux/Windows parametrised commands utilities- these are either direct low level native #GridSscript instructions or high-level utilities implemented using the former.

Basic Concepts

For the purposes of this Tutorial keep in mind the following simple concepts:

Invocation of each instruction comes at a cost. Similarly like in Ethereum. The more resources (CPU/storage/memory) the instruction involves, the more costly it is. Each low-level #GridScript instruction has a cost associated.
The ⋮⋮⋮GRIDNET VM. Everything you type is done within a ⋮⋮⋮ Virtual Machine. While you play Crypto snake, it’s the ⋮⋮⋮VM serving you each and every frame. Each time you connect either through SSH or access ⋮⋮⋮Desktop through web-browser, a fresh new instance is spawned for you and killed automatically once you are done or should the system detect any kind of abuse. Even the ⋮⋮⋮GRIDNET Token mobile spawns 1-2 VM instances as needed.
The Sandbox Mode – what’s important to note about the ⋮⋮⋮GRIDNET VM? By default it operates within a Sandbox. A certain amount of assets is arranged for your connection and you are free to use these assets as you see fit. However, none of these operations would permanently affect the decentralized state-machine. Results of your instructions/commands/operations, asset transfers.. these would only live within the current state of your Sandbox.

Escape The Sandbox💫

Can we escape the current reality as we know it (while keeping ‘alive’)😵‍💫? At least for now we don’t know how😆. Luckily for us we can escape the ⋮⋮⋮GRIDNET OS’ Sandbox and have the results of computations affect the entire Decentralized State Machine thus at high redundancy and security.

How?

That is not overly difficult!😊.

Before executing instructions, use the Begin Transaction command (‘bt’)
When over, issue Commit Transaction (‘ct’)
at any moment you may see the auto-generated transaction’s source code by using View Transaction (‘vt’)
even when using ⋮⋮⋮GRIDNET Desktop, all your actions are translated into #GridScript under the hood by the ⋮⋮⋮GRIDNET OS JavaScript Context

That’s it. The system would then guide you through any questions if needed and present you with a QR Intent which you would scan with your mobile app😁. Within the ⋮⋮⋮GRIDNET Desktop graphical environment things will be even easier and definitely more pleasurable to look at 😉

Let’s now get into some more details.

Each instruction which affects the state of the ⋮⋮⋮VM puts it into another ‘perspective’. Perspective is the identifier of its state. State-Domains may exist in multiple perspectives at the same time, but only the most recent one is the effective one. All others are assumed to exist in the past.

How does one get to know the current perspective? easily. Simply type… ‘perspective’ within the Decentralized Terminal Interface:

Getting to know the current Perspective

You may just think of it as the current perspective on things indeed.

You may choose to make your current ⋮⋮⋮VM switch to any perspective from the past by using the ‘sync’ command.

How does one get perspectives from the past? For one let me go into my home Directory and execute the ‘info’ command.

Previous States of a State-Domain (i.e. account)

The domain has an ID token registered as well.

Here I can see that my State-Domain (i.e. account) is available in 10 perspectives. The last one at index 9 is the current perspective.

I can choose to time-travel all the way back to the first state. For this I type ‘sync’ followed by the perspective of my choice.

Synchronizing with a chosen perspective.

if I type ‘sync’ alone, the ⋮⋮⋮VM will synchronize with the current state of the network i.e. with the most recent perspective.

Synchronizing with the current world-view.

Let me see if it actually worked by checking the reported balance:

Balance seemingly differs from the one in the past.

Certainly it worked! 😁After all, it’s been conceived, researched and implemented by Wizards🧙. How could it not😆.

As you may see above, the values are different. It’s like using a Time-Machine. Congratulations! You’ve just learned not only how to escape the Sandbox, you’ve already learned how to teleport yourself back and forth in time! Can Ethereum do this? Don’t think so.. Let’s keep going!

The story about Ethereum

Why is Ethereum being mentioned in here? Well, to get a better perspective on things in short. Folks behind Ether never managed to research and implement effective data pruning for their VM. Here such mechanics are integrated on day 1. Not only that, as you’ve just seen, you may teleport yourself back and forth across states with ease.

Accessing previous state in Ethereum is impossible in short, from the perspective of a smart-contract.

Here are sample places where you may read up on these subjects:

Folks at Ether built up on Bitcoin.. well, we’ve researched everything from the bottom up there’s not a single line in common with other projects. We’ve learned from the best and what you’re seeing right now is a true peace of Art. It is🙏.

State-Channels and Off The Chain Transactions

These are already described quite a lot within the White Paper as far as theory goes. Here we are about practice.

What’s wrong with on-the-chain transactions? Is there anything wrong with these?

As you might know, decentralized state-machines, they’ve got a problem. They do not scale so well. If somebody is trying to sell you yet another decentralized computer, you might want to think twice. You need to be aware that both Bitcoin and Ethereum these are products. Somebody is trying to make money on. Either by being an owner or by trying to make returns from investments. Both of these are brands. Both can be assumed to be riding on the peoples’ lack of technical knowledge to some extent. Back when Ethereum was coming out, it caught many by surprise. It actually painted visions of a decentralized computer whereas they’ve ended up with a DOS-like code execution system nobody knows how to use. Sorry, there’s no decentralized computer from the perspective of a typical end-user as far as Ethereum goes. There never was to be. Don’t get me wrong. Folks at Ether, together with its mastermind, Vitalik, they did a lot. But all in all it can be said that just the Bitcoins’ programming language got replaced by a different one.

Let’s get back to off-the chain and on-the-chain transactions.

Be it Bitcoin, Ethereum, or even ⋮⋮⋮GRIDNET OS. Changes done to the decentralized system, they need to replicate across the network. Thus transactions no more are only financial transactions sensu stricto but are closer in their meaning within the data processing realm. They can represent arbitrary authenticated operations that are to be executed by nodes maintaining the system.

Now imagine millions of users use the platform simultaneously. What happens? It gets stuck. What if you were to reward for propagation of data packets of the entire Internet? Would it be possible? Well certainly not with the current blockchain systems.

Enter ⋮⋮⋮GRIDNET OS which boards unique implementation of the researched by us State-Less Blockchain Channels, and the related Multi-Dimensional Token Pools.

Here we are after practice not science so lets stick to it.

The Snake Multiplayer Game🐍

A tutorial describing how to play the game is available here.

Here we are after more technicalities, we will also get to see how to cash-out the received tokens. So that to receive the actual ⋮⋮⋮GRIDNET Bacis Units (GBUs)

The game, when launched, tries to access a token pool which was made available by the full-node’s Operator, the one the user is connected to.

For this to work, the operator has to do sacrifice a certain amount of assets. Those sacrificed assets were not ultimately lost, however. Those would be used to create an off-the-chain value store. The data store is represented on-the-chain by an innovative data structure nicknamed the Multi-Dimensional Token-Pool. The total cumulative value comprising the token pool is up to the value of the sacrificial transaction. Each Pool is comprised of (multiple) dimensions. You may think of each dimension as of a bank. Each such bank can be used to keep rewarding single, unique recipient. When rewarding from the given bank one keeps releasing new versions of a Transmission Token. The recipient may choose to cash-out the Transmission Token anytime but each such operations involves a fee, thus it’s in the recipient’s best interest to keep receiving updated versions off of Transmission Token as long as possible (until resources from a given dimension get depleted or once the recipient is not to receive additional rewards) and cash maximum value at a single processing fee.

Sounds reasonable? It is😊.

So. For you to be able to receive rewards by playing the Crypto-Snake🐍 game, the Operator sacrificed 10 MILLION GBUs. Now that’s a lot 🙃.
The Operator used the receipt of the sacrificial transaction to generate a Token-Pool. What are some of the important Token Pool details?

It would be best to take a look at help displayed by the Token-Pool generation utility:

The Token-Pool generation utility.

The value – this one is computed automatically for you. The token pool generation utility takes the receipt of a sacrificial transaction and looks it value up.
The number of dimensions. – that parameter tells how many peers you’ll be able to reward simultaneously. The more dimensions the bigger the Token Pool’s data structure and the more expensive it will be to deploy. From our research it turns out you should never be in need to use a token pool with more than 30-100 dimensions. Even when using things like a decentralized YouTube, we plan to deploy.
Value of a single token – that also gets calculated for you automatically if you don’t provide. It’s the value of a single token within each of the dimensions. Note: value tokens within each dimension are the same.

Let’s go about generating a Token Pool of our own!

A sacrifice needs to be made.

First I sacrifice 10000 GBUs. The QR will be shown I confirm on the mobile app.

Confirming sacrificial transaction with the mobile app.

Nice! The important thing to me is the Receipt. I’ll use it while generating the Token Pool.

Let’s go about using the token-pool utility now.

Important: We are about to issue yet another transaction. Once containing a Multi-Dimensional Token Pool which will be generated by the mobile app.
Thus, we need to bing the ⋮⋮⋮VM into the current state. Otherwise nonce value associated with your account as seen by your ⋮⋮⋮VM, one used by the Transaction’s Composer would be out of sync and the resulting transaction – rejected. Use the ‘sync’ command now to synchronize with the network now.

Time to generate the actual Token Pool.

I’ve synced and executed ‘genpool’ just to see the help screen.

Time to begin formulating new transaction by executing the ‘Begin Transaction’ command, i.e. ‘bt’.

and then executing the ‘genpool’ command by providing it with the sacrificial transaction,meaning the Receipt of it.

Let’s go! You’ll be notified that quite a big QR Intent is to be rendered within the Terminal. The system attempts to automatically detect the size of your Terminal and warn you or even pause execution and wait for you to increase the Terminal’s Width (by resizing its window) should ⋮⋮⋮GRIDNET OS detect that the width is insufficient.

Enormous QR code on the way let us not be afraid.

Certainly the mobile app handles it just fine.

That’s quite a BIG QR Intent indeed. Rendered using UNICODE 1.1 characters from the DOS era. The technology never ceases to amaze us.
The mobile GRIDNE Token app seems to have no trouble scanning it as well.

Once scanned you’ll be shown with a mobile screen looking like one on an iPhone below:

Looking good. Certainly the app understands.

The app says that you can SWIPE your finger for more. And it actually means it! Let us try shall we 😁 Simply swipe to the left on the upper bluish field.

Well, indeed it does.

What just happened? How does the app know.. how does it understand what I’m about to commit? 🤯 Well:

the mobile app boards a #GridScript decompiler of its own
in some cases the mobile app is required to perform computations on its own so it needs to understand perfectly well what’s being done and how the results of computations are about to be delivered to the network.

Here the app, being the only trusted device on the system as per our Security-Threat models, is asked by one of the full nodes to generate a Token Pool. See, the Token Pool couldn’t be generated by the full-node itself as the resulting data structure needs to contain a secret value which cannot be known to the full-node itself. See.. Wizards🧙🧙‍♀️ really, really.. they took their work.. seriously. They’ve saved upon nothing 🙏

The description which you see is generated dynamically. Really. What you’re seeing is dynamically generated HTML and CSS representing the tasks to be executed by the mobile app. The app strives to provide as accurate description as it possibly can. The cool thing about it is that the app can represent operations it has never been initially prepared for or operations that Wizards🧙🧙‍♀️ haven’t initially envisioned.

If you’ve kept track of the Project for some time already you know very well that the autonomous remote Log-Me-In functionality described here has been implemented and deployed without requiring any updates to the mobile app itself. It simply worked and provided custom, new messages within the mobile app’s UI.

Let’s keep going and confirm actions within the mobile app. An onion routed connection to the very ⋮⋮⋮VM hosting your SSH session would be initiated and established. The mobile app would keep notifying you upon any changes to its status. Interestingly the app receives updates about both the network-layer connectivity, the decentralized state-machine operations, results of tasks related to the remote peer.. and a few others😆 Quite smart it is, still everything is wrapped in a very minimalistic UI with all the details hidden away for your convenience.

Onion Routing data to the network.

If everything goes well, soon enough you’ll get to see confirmation within the SSH terminal that a Token Pool has been generated and delivered from the mobile app. The representation of the token Pool Delivered from the mobile app is ‘disarmed’, meaning it does not contain the secret value but it is enough to be put into the decentralized state machine’s storage and validate any consecutive token you might be issuing on its behalf later on.

Disarmed token pool generated by the mobile app has been delivered to the Terminal.

An interesting thing to note: the ⋮⋮⋮VM has already generated, fully autonomously, source code of a transaction whose instructions instruct the decentralized state machine to register the very token pool you mobile app has just delivered. How cool is that? How amazingly sophisticated. Let us keep going, shall we?

You may view the transaction’s source code by using the previously mentioned ‘vt’ instruction. There could be a very short friction as the source code is generated. The large portion of text is the base64 encoded Token Pool your mobile app has just provided.

Lurking into the source code of auto-generated transaction..

As you may see the entire transaction is 5723 bytes in length.

The wall of text is base64 encoded TokenPool data.

Let’s commit! There’s nothing to wait for. Use Commit Transaction (‘ct’). The ⋮⋮⋮VM would automatically calculate the costs based on the encountered transactions. All you need to do is accept the proposed values🙏.

The VM would now show yet another QR intent which asks for your permission to sign and broadcast the just generated transaction. Once you confirm the mobile app would sign it and then onion route it across the network (end-to-end encryption for anonymity at all times).

We need to broadcast TX instructing for registration of the Token Pool.

You are constantly being notified about results…

Done!

Presumably the transaction got published successfully and is now being processed by the decentralized network of full nodes.

At any point you may check status of the previous transaction by using the ‘getresult’ command. If you don’t provide parameter, it will check the result of the most recent transaction. You may, however, provide it with a custom receipt. The utility would contact the network and fetch result along with the stack-frame including meta-data should anything have gone wrong.

In the end token pool is stored within a file on the decentralized file-system.

Luckily, everything went just fine. Like above you may CD into my directory i.e. use ‘cd /CodesInChaos’ and then enter the TokenPools directory to see that the token pool under the name ‘sample’ indeed is there. What a joy! You may also use full path right away ex. ‘cd /CodesInChaos/TokenPools’

We may see into it with parameterized Linux-like commands.

‘sample’ is just another file on the GRIDNET OS’ Decentralized File System. This very file is stored in the GRIDNET OSEternal Storage, meaning full redundancy at each and every full-node.

You may use Linux-style ‘less’ command to view its contents. You may want to use the -tp parameter so that the binary interpretation layer kicks in and the binary code is treated as a Token-Pool with all the fields depicted as in the picture above.

How to be using Tokens From a Token Pool will be a subject for another tutorial! Something is telling us you’ll be getting to know how to use these from the GRIDNET Desktop Graphical User Interface very, very soon 😁.

Cashing Out Of Tokens

So you’ve played Crypto-Snake a lot and now you want to cash-out your rewards? It’ve very simple.

Say I had my current Snake Token equal to “CETH71fZGK8nc6yctJBjKTzy7cG92DSsRQhGA6aUzbP5uN82p4zY1VoWo3LLzz3PvQ9uH63zz5bGts3VaZ2myS6oKDadKKYeYi4HchcivMwcqHq799z9dqPnkXajfT1”

Let’s see what the xtt command shows when I try to cash it out in SandBox. We may use the ‘xtt’ command, as in the picture below.

Cashing out of Tokens generated from a Token Pool.

so looks like I would get 10GBUs were I to wrap this code in BT <-> CT block and commit.

If I want more, I can play Crypto snake further by providing this token during game start

While playing, I gathered 2 bags of coins. The app provided me with a new token equal to:

racTiXpHsLyVTfBzNp43A4GK1Pyfmjy3GPFZL54MU3jtm9DX6cyx1DjUxbCy6rY2C9ZcYxYjnNpb6VFEb6fXeykxjq6Nui6tgoiAW6TLDpg122R99F6qv6W74CXSKriK

having more!

Let’s try to cash it out shall we !

The system recognizes the additional reward.

Looking good! After collecting 2 more bags of coins in single-player I now have 30GBUs to cash out. Note that it’s not really worthwhile for me to do so since the fees are higher than the rewards. Gotta play Snake some more!😆.

Thank you for reading stay tuned!

This post has been written by CodesInChaos ~one of the Wizards🧙🧙‍♀️