dApps Engine

dApps Engine is the system through which to load the dApp (Decentralized Applications) directly on the blockchain. If in an absolutely alpha state, the engine allows to load (IdaNode side) and execute (client side) the code and the dApps.

The Scrypta philosophy is to start the dApp directly in the user device, so as not to overload the network (even if large) and avoid the bottlenecks that would derive from the use of large-scale "cloud" computational power. In fact the idea is that the nodes must interface with the Blockchain and the dApp must be executed by the devices. The interaction happens precisely thanks to IdaNodes, which allow reading and writing operations and which can always be started locally.

The dApps, in effect, are loaded on IPFS, and the folder containing the files is written on the blockchain. Since the folder is represented by a hash, this will change every time changes are made. These changes can in turn be written to the same address, so as to have a sort of versioning available on the blockchain. The actual authenticity of the update lies in the fact that only the developer will have the private key of the address.

These operations, which are currently done manually, can be performed through a graphical interface in the Developer Portal, which is under construction.

We can define the dApps Engine a milestone for the entire ecosystem. It will be strengthened and made a stable product over the coming months. Here it is possible to follow its development: https://github.com/scryptachain/scrypta-dapps-engine

[POST] /upload

The endpoint available, at the moment, is to upload the dApp and consists of two steps:

  1. Loading the folder with the files on the IdaNode.

  2. Saving the transaction containing the dApp information.

These operations could be performed via the dedicated endpoints/ipfs/upload and /write.

The fields to fill are the following:

  • files [mandatory]: the dApp files, sent via form-data

  • dapp_address [mandatory]: the dApp address

  • private_key [mandatory]: the private address key

In near future we foresee the possibility of inserting further fields to identify the version type, dApp name, logo etc. This will be used to create a decentralized App Explorer where anyone can publish his dApp.

The endpoint response, if everything has been correctly validated, will be similar to write operation:

{​ "uuid": "ee0e4794.7b69.476a.a49b.c4bdaa078ab6",​ "address": "LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2",​ "fees": 0.002,​ "collection": "",​ "refID": "",​ "protocol": "dapp://",​ "dimension": 107,​ "chunks": 2,​ "stored": "*!*ee0e4794.7b69.476a.a49b.c4bdaa078ab6!*!!*!!*!dapp://*=>QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA*!*",​ "txs": [​ "f76cb402f844f4b11566b5ace76f7f94559febcf17a757f2079ed1e2a8ccd2a6",​ "5382ee73823a8676320fb554a43d78928c80babb72509d79d4b5d089483743c7"​ ]​}

If we analyze the data entered, ie QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA through the enpoint /ipfs/ls/QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA we will see that it actually contains our newly loaded folder:

[​ {​ "hash": "QmaWcMiVPLMePAspNqhY7U4ByDDmuTKDitogWDwUCoo49x",​ "path": "QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA/dapp.js",​ "name": "dapp.js",​ "depth": 1,​ "size": 204,​ "type": "file"​ },​ {​ "hash": "QmYFPVBraRnzMguR7SwyKMtvo2ZzUThUAcrRkQ1TEv6Mci",​ "path": "QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA/index.html",​ "name": "index.html",​ "depth": 1,​ "size": 1042,​ "type": "file"​ },​ {​ "hash": "QmQVKoAs9nxjRfawb6ALhZNEzpR5RFBgN7FeJdAZYWdN8h",​ "path": "QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA/logo.png",​ "name": "logo.png",​ "depth": 1,​ "size": 2381,​ "type": "file"​ },​ {​ "hash": "QmYzaWGQM7b224S8taaiVVUzt1h56tudncDn7Ds45G7wcV",​ "path": "QmeHZ86FBr2nZ6fdQk32qkXQXCs6wELE6Ldo584k3TWLMA/scryptacore.js",​ "name": "scryptacore.js",​ "depth": 1,​ "size": 477293,​ "type": "file"​ }​]

Thanks to our tool we will see that the dApp works and is loaded directly by IPFS: https://scryptad.app/LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2

As you can see, the address LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2 that wrote the information, is actually re-called and, in the background, the following operations occur:

  1. The address LdRQokR1i3XDtj1V3jnCRqMPrVc7sYkeE2 is read and the last data is requested.

  2. The folder is read, as seen above, and the index.html file is served. If the file does not exist it will return an error.

  3. All other assets are actually served, always reading them from IPFS.

Now your device (using the browser) will have a cached copy, and it will be the computational power of the device to be used. In no case will these files be downloaded to the dApp engine. As a result it will remain performing and will serve all the assets on-the-fly.

This is a typical engine log:

engine log

As you can see, all the steps described above are carried out.

Congratulations, you have just created a decentralized application!