âī¸Runners
Let's look at where smart contracts of the new generation will start. Also, it's entry point for Thundercloud
Where it all starts
After you have managed to get acquainted with the capabilities of the services, it is time to tell in more detail how they will be performed, what and where they will be launched, and how it works in general.
On KLYNTAR, all services will somehow go through the runner and its rules. A runner is like a middleware that receives a service from the network and, based on its settings, makes decisions like
Is it worth running a service?
How and how much memory to allocate to a service
Whether to set any restrictions
What is the security budget and how many security centers have checked this repository
Is the address in the trust tree?
How much can you potentially receive from this service Is it worth it to distribute and advertise the service further on the network?
...and other solutions
The runner decides whether to run the service on this node or send it to others, whether to give access to the network for the service, whether to run it in a separate container or in one of the existing ones, and so on.
Here's how you can schematically represent the runner
In a nutshell
The nodes listen, distribute and download repositories (if a location is given) or compressed archives (if the service is distributed directly) and following the rules and settings of the runner decide how to run the service.
Due to the independence of runners from the network and its processes, as well as continuing the theme of modularity, we will allow users to use custom runners for their infrastructures, as well as provide the possibility of flexible configuration and customization for maximum efficiency.
Although you determine the functionality of the runner yourself, we still recommend that you focus on official solutions as the most effective ones.
Runner at the code level
At the code level, the runner is a separate repository that lies in the KLY_Runners directory. You should already be familiar with the principle of how we store data, but we will still show the directory structure for clarity.
Here, for example, how it looks at the level of the code editor
You can update repositories independently. The KLYNTAR daemon, when it starts, looks at the services.json configuration file and the RUNNER option where the path to the runner entry point is specified.
Here's what it looks like. ĐĄonfiguration file services.json
runner.js is the entry point of a runner that exports an unnamed function that receives an object of a standard structure as input and is taken to process it.
Here's what it looks like
As for the worker processes, since they make up a set of route handlers and create routes to the server themselves, they must provide a handler for the runner to simply receive data from the network, pass it to the function, and then the runner will do its job.
For example, the dev_tachyon workflow provide these handlers
As you can see, the server simply accepts some JSON service object and passes it to the runner for processing, while it simply sends a simple HTTP response.
Runner configuration example
In order to further understand the principle of operation, you can look into the configuration
Here the runner can determine from which resources it is allowed to download files, determine the containers with which it will work, set trusted centers - these can be multisig addresses that, for example, will send you a signature about the security of the service and you will make sure that if a certain number of addresses have already voted for the security of the service with a total balance of more than several million KLY and other options.
All this once again emphasizes the flexible possibilities of KLYNTAR and the possibilities of runners.
Default runners
By default, the standard runner from the KLYNTAR developers will be available to you. We named it after our neighboring galaxy Andromeda. This is symbolic since we are comparing conventional smart contracts with our relatively well-known Milky Way galaxy. But the services in the form in which they will be on KLYNTAR are something new, some kind of new galaxy - not so distant, but still - opens up new opportunities for us
Currently, all runners are under development and will not be available for the first time for use on the network.
Runners and Thundercloud
Runners will be used in our project Thundercloud to build the decentralized, open-source and mutable cloud. Details soon
Last updated