Everything starts at the beginning
The fun begins…
The heart of each system is architecture. With this article, we start probably the most interesting cycle of articles in our blog.
In the following sections & articles, you will learn about how KLYNTAR works, its components, architecture, workflows, and so on. We will try to give both a good general idea and dive into some details so that you can easily start studying further sections.
It is also worth warning that KLYNTAR may seem complicated to you initially, but in our world, everything works like that. Computers, economics, physics — all this is difficult to some extent, but only because there are great opportunities behind it.
If you have any difficulty understanding, do not hesitate to ask us questions. We also expect you to actively participate in the development of the project.😀😀😀
Flashback
In our first article, we’ve promised you that KLYNTAR is
- The most decentralized project
- The fastest project
- The most secured project
In this article, we are going to explain and show you why is it true. Let’s start with security & decentralization(paragraphs 1 and 3).
KLYNTAR architecture pillars — hostchains and symbiotes
Let’s take a look at a general system. This picture is taken from our initial whitepapers, so something might be outdated or without new features, but anyway it contains what we need now
In KLYNTAR there are 2 types of chains — symbiotes and hostchains. Let’s figure this out so we can move on. To understand this, I need to tell you about multi-level sharding and the idea of common security.
KLYNTAR ecosystem consists of many independent chains called symbiotes. Let’s define what it is:
Symbiote — an independent chain in the KLYNTAR ecosystem with its own state, blocks history and rules like protocol, consensus, etc.
It’s like shards in other sharding implementations, but not the same. It’s the first level of sharding(sharding-by-default)-soon I’ll tell you about the sharding inside a single symbiote(pool-per-chain).
For instance, the initial symbiote(labeled as kNULL) will be run by KLYNTAR team and this day will be the date of launching testnet / mainnet🚀🚀🚀
Symbiotes can be launched by our team and the community, as well as third-party organizations and teams who want to create their own blockchain (for example, private or semi-private) and join the common security & speed.
NOTE: In this picture, you see the “workflow” definition under symbiote. We’ll talk about it in the following articles, but now you can think about it as a set of rules & modules used by each symbiote — consensus, virtual machines, custom algorithms, etc.
So far, it is not clear where the vaunted super security comes from🤔🤔🤔
It is because we should get acquainted with such a component of the project as hostchains. As you know, a symbiote is an organism that needs a host in order to survive. The role of hosts is performed by hostchains — self-sufficient chains like Bitcoin, Ethereum, Solana, Near, Toncoin and so on.
Their common security like decentralization, number of validators, TVLs on smart contracts and so on protects KLYNTAR from state rollbacks, and consensus-related attacks like long-range attack, sybil attack, etc.
But how???
First of all, let’s talk about the interaction of symbiotes and hostchains. So, their relationship is similar to “many-to-many” relationships in databases. Both symbiotes and hostchains are blockchains, but the former relies on the general security of the others. How?
Well, the first type of interaction we’ll talk about is symbiote state commits to hostchains. The idea is that all symbiotes in the ecosystem periodically save a hash of their state (or any other proof, such as the latest block hash, an epoch hash, etc.) on the hostchain blockchain. Depending on the hostchain, this can be done through smart contracts (in Ethereum, Solana, etc.) or through special transactions (for example, OP_RETURN in Bitcoin and forks).
Thanks to this, anyone can be convinced that a certain state X of a certain symbiote is the only possible valid state of the chain. And due to the fact that this proof in the form of a hash will be stored not on one blockchain, but on several (Bitcoin, Ethereum, Solana, and others), then by summarizing the indicators of the Nakamoto coefficient, we get the maximum guarantee of eternity and non-rollback of data in the symbiotes chains, because no one there are no such resources to rollback Bitcoin + other cryptocurrencies on PoW, as well as to carry out attacks on a major part of BFT / POS based projects that involve staking.
For example, here is the list of Nakamoto coefficients of other networks
The enemy should now take control literally over trillions to take control over the majority of these hostchains. But behind each blockchain project, there are different investors, different states, different jurisdictions, and so on.
Hope you understand that the division of the ecosystem into symbiotes was the first level of sharding. We need this so that each symbiote, working autonomously, can only interact with a small group of hostchains and periodically interact with them. By default, we use this rule:
1 symbiote uses 1 hostchain
When the time comes, symbiotes commit the state to their hostchains, and then other symbiotes transfer this data to their hostchains, saving the states of other symbiotes as the root of a Merkle tree, or simply as a hash with a list of the form “symbiote x — state y”. Thus, each of the symbiotes is formally spent only on transactions in their hostchains (after all, calls to smart contracts require money), but thanks to such a common security system, their state is stored in other hostchains. You can see the visualization of this process below:
So, what does it mean?!
It means that not this is cool:
…or this:
But this😍
Summary
Phew! And here is the finish. In this introduction article from the new cycle, we started with KLYNTAR architecture. We talked about types of chains in the KLY ecosystem and now you know what is symbiotes and hostchains.
Also, you have some understanding of the mechanism of common security & decentralization. We mention this in the first article and now you know more.
What next? 👻 In the next article we’ll continue talking about the pillars of security of KLYNTAR:
- Multistaking
- Tachyon — a monstrously fast, multithreaded, deterministic, totally asynchronous BFT-based consensus mechanism with multi-million TPS, no limits on validators and other interesting features
- Spacing Guild👽 and social consensus
