đConnectors
Smth what links blockchains
Role on KLYNTAR
Connectors are modules that encapsulate work with hostchains. They export functions for a wide variety of interactions, from simply storing commits on hostchains, to more advanced logic like using zkSNARKs and executing contracts. These functions are then used at the workflow level to interact with hostchains. Connectors are usually distributed in packs for greater convenience and classification.
Since we have to adapt to the functionality of other chains, all you need to write your own connector is to study the API, SDK or documentation of the hostchain for which the connector is intended (or groups of hostchains if there is a common interface like that of EVM compatible blockchains.
Here's how to schematically label the connector so that you have a better understanding of what is happening
Connector configuration and configurable parameters
The connectors also have a set of necessary configurable parameters - a pair of keys to work on the hostchain, an endpoint URL (this can be your node, a node from your pool, or even a Node-as-a-Service decentralized service on KLYNTAR) and some more settings.
Flexibility and depth of settings are determined by the creator of the connector.
Within certain standards, workflow provides an HC_CONFIGS object which contains the necessary configs for the connector. In order to show in practice, for example, here is how the configuration of one of the workflows that uses a set of symbiotes looks like.
The set of custom parameters is defined in the connector. It all depends on how cool the connector is and how much it allows you to configure.
In this case, connectors for 3 hostchains are used:
Litecoin
Ethereum
BNB
They are all from the dev0 pack. Let's take a look inside
It is also worth noting that this pack contains not too "cool" connectors. This group of connectors simply save the commit to the hostchain and then check the commit asynchronously
Let's look at the code of the connectors to make it more clear to you. Here is the connector for Litecoin
Inside the function, you can see how the connector accesses its settings through the global CONFIG.SYMBIOTES[<symbiote>].HC_CONFIGS object. This is exactly the same object that we configured at the workflow configuration level.
Likewise with other functions. You can explore the repository yourself for a better understanding of how it works.
And here is an example of an EVM compatible connector. This is another proof of KLYNTAR's flexibility - because thanks to 1 connector, symbiotes can communicate with all EVM compatible blockchains.
Here you can see how the connector uses standard parameters to work with EVM compatible blockchains. There are familiar terms like GAS_LIMIT and GAS_PRICE, you can choose CHAIN_ID according to this resource (to work with different networks) and much more.
Internally, this connector works by following the Web3 documentation and the JS toolkit for working with the EVM.
Inside the connector
Connectors in general should be an exported object that contains all of the connector's functionality in its methods. Also, the connector may have some additional dependencies of its own (and therefore it will be necessary to load them) or require some operations on the code (compile something inside the module, etc.)
Here is what the general structure of the connector looks like
Imagine that there are EVM (Ethereum, Polygon, Avalanche) chains. In order to make sure that they ensure the safety of the KLYNTAR symbiote, you need to write some kind of connector. What can we think of? Well, the simplest option is to simply store state in a chain, as demonstrated above - without any two-way logic with smart contracts (especially when it comes to Bitcoin and the like, where they do not exist as such).
For such a simple connector, you probably need something like the functions setCommit (in order for some symbiote to save the commit) and checkCommit (in order to check the inclusion).
In this case, your connector might look like this:
Mutual work of connectors and workflow
Since we want the maximum, both connector developers and workflow developers should make their modules following the practice of being as flexible as possible. This will allow the same connector to be used by completely different symbiotes and their workflow
Using connectors at the workflow level
Again, the simplest workflow (dev_controller) can be cited as an example. This is how he uses the connector in his code.
This is the block generation function. As part of the workflow, it is planned that a new commit cannot be added if the old one is not yet included in the hostchain. In addition, the logic of periodic activation is defined at the connector level. So, for example, on Bitcoin and forks (due to the common API and similar data structures) you can set the CONFIRMATIONS parameter and thus the commits will be only at set intervals (due to the fact that on Bitcoin there is a difficulty correction and the network in any case mines a block approximately once in 10 minutes). But this is just an example, other connectors may be more functional and provide other cool features.
Function entry poin https://github.com/KLYN74R/KlyntarCore/blob/0cd166e7790e9ddeac9d3d3b8ce069689bdba13b/KLY_Workflows/dev_controller/life.js#L137
Here, just for flexibility, the workflow developer could come up with something for the workflow. For example, a block would be generated if it reached a certain multisig staking threshold, and so on.
This page will still be updated as the topic of connectors is very large and exciting.
Last updated