simbioty.md

description	cover	coverY
Биты в мире блокчейнов. Самостоятельные блокчейны и концепция sharding-by-default	../../.gitbook/assets/tumblr_b800eb940c93611ad96334db121b1cf4_2323ada7_1280.webp	-14.419354838709694

👽 Симбиоты

Почему абстрактность важна

Мы строили KLYNTAR из соображений того как работает современный мир. Контейнерные перевозки, стандарты USB, маршрутизация трафика - всё это в мире взаимозаменяемое и одинаковое повсюду. Разрабатывая KLYNTAR мы не пытались "захардкодить" туда консенсус, менять который потом надо будет 8 лет, не пытались привязать жёсткое количество валидаторов или навязать какие-то жёсткие ограничения.

Именно поэтому, в основе архитектуры лежит принцип модульности когда каждый отдельный симбиот может строиться как конструктор, самостоятельно выбирая консенсус(обобщено в KLYNTAR под названием workflows или рабочие процессы), набор хостчейнов, тип взаимодействия с ними, собственную комиссионную политику и так далее.

Фактически, KLYNTAR так же является фреймворком для создания собственных блокчейнов для ваших нужд, а наличия KLYNTAR Services помогут вам запустить их параллельно основным симбиотам и получить безопасность и возможности KLYNTAR прямо из коробки - только теперь игра будет по вашим правилам.

Несмотря на это, есть ряд "стандартных" и "общих" компонентов каждого симбиота. Так, к примеру стандартная реализация ядра KLYNTAR написанная на Node.js включает в себя некоторые общие элементы для всех симбиотов такие как:

• Реализация сервера
• Основной файл-запуска (klyn74r.js)
• Создание общих файлов и директорий(обычно конфигурационных)
• Создание некоторых общих глобальных переменных(например приватные ключи или объект глобальной конфигурации)
• Запуск плагинов
• ...и всё😅

Всё остальное - модульно настраиваемо и зависит от симбиота. Мы поговорим об этом детальней дальше на этой же странице.

Что из себя представляет симбиот?

{% hint style="info" %} Симбиот - это отдельная цепочка, которая имеет свой генезис, свою историю событий, свое состояние, работает следуя своим рабочим процессам(workflow) и взаимодействует со своим набором хостчейнов {% endhint %}

Подобная структура напоминает сетку Рабица

В такой структуре нет слабых мест ведь все связаны друг с другом и всё это при участии других сетей.

Мы так же говорили о росте состояния сети и перераспределения нагрузок. Ввиду того, что симбиоты - это множество независимых цепочек, то каждый из них "перетягивает" на себя часть транзакций, пользователей и так далее.

При этом, состояние сети(актуальные данные) и их история(собственно сам блокчейн) не складываются в большую и тяжёлую цепочку. В Bitcoin или других сетях вы обычно можете быть уверенными в достоверности состояния сети и ее безопасности только если сами станете полным узлом, будете хранить весь блокчейн и так далее.

В KLYNTAR к примеру, если у вас есть SSD на 256 ГБ, то вы сможете поддерживать, к примеру, 1 симбиот, если есть больше - то сможете больше и так далее. Требования к вам не являются статичными, мол "вам нужно хранилище на 1000 терабайт" и сервера на 100 000 ядер. Вы сможете быстрее синхронизироваться и вступать в работу, а это очень благоприятно сказывается на децентрализации сети и легкости входа. Тот же принцип и с сервисами(KLYNTAR Services) с которыми вы познакомитесь в дальнейших разделах.

Из чего состоит симбиот?

Workflow

Первый и основной компонент каждого симбиота - это его рабочий процесс.

{% hint style="info" %} Мы постоянно указываем workflow потому что в русском сложно подобрать подходящий перевод {% endhint %}

Workflow - это модель работы некоторого блокчейна. Тут определяется консенсус, определяется набор событий(разные транзакции, заморозки счёта, выполнение смарт-контрактов и т.д.), определяется набор маршрутов для сервера(для коммуникации нод между собой) и много другое. Давайте разбираться.

Workflow будут находится в директории KLY_Workflows. Каждая сабдиректория будет репозиторием для отслеживания версий. Вы можете это увидеть на GitHub

Здесь вы видите 3 workflow - dev_controller,dev_tachyon и dev_helloworld(шаблон для написания собственного workflow)

dev_controller представляет из себя централизованную версию рабочего процесса. Здесь 1 валидатор, однако блоки генерировать могут все у кого есть соответствующая ставка.

Пусть вас не пугает наличие 1 валидатора по нескольким причинам:

• Это удобно для локального тестирования и запуска тестнета
• Это максимально быстрый workflow ввиду отсутствия множества сторон. Симбиоты с таким workflow могут запускаться каким-то "достаточно доверенным лицом"(например биржей или какой-то организацией) следуя что-то типа модели Proof-of-Authority
• Главный валидатор всё равно не может отклонять транзакции(благодаря мутуализму и SpookyAction) или менять историю цепочки(благодаря хостчейнам и общему бюджету атаки)

dev_tachyon будет молниеносным, асинхронным, с многомиллионным TPS, максимально параллельным BFT блокчейном с использованием стейкинга(в том числе стейкинга с унобтаниумом), BLS мультиподписей и прочих интересных фич

{% hint style="info" %} В настоящее время все workflow находятся в разработке {% endhint %}

{% hint style="warning" %} Сейчас мы не вставляли сюда подмодули Git и поэтому вы не видите характерной иконки. Как говорилось ранее - к релизной версии может всё поменяться, но так же мы предполагаем что наиболее используемые workflow будут частью ядра, а не распространяться отдельно {% endhint %}

Мы предполагаем наличие нескольких workflow, однако, ввиду понятий про "хорошие и быстрые блокчейны" будет только несколько основных которым будут пользоваться все. В целом, даже наше разделение на workflow с контроллером(dev_controller) и на децентрализованный dev_tachyon уже выглядит достаточным_._

Коннекторы

Вторым важным компонентом симбиотов являются коннекторы - модули для работы с хостчейнами. Вы более детально познакомитесь с ними в разделе Коннекторы, но сейчас просто скажем что они определяют то, как ваш симбиот взаимодействует с хостчейнами.

Разработчики коннекторов, к примеру, создают для вас интерфейс, предоставляя функции для работы с определённым типом смарт-контрактов на хостчейне который их поддерживает или же другие методы взаимодействия.

Разработчики workflow затем берут эти коннекторы и вставляют в свой код в нужные места. Например, отправить коммит состояния на Ethereum и Tron где в качестве пейлоада будет мультиподпись валидаторов или же сгенерировать zero-knowledge доказательство и отправить его в EVM на какой-то контракт вашего симбиота.

Так а что нового можно придумать?

В этом и сила модульности рабочих процессов - вы можете придумать всё что угодно. К примеру, один симбиот будет запущен группой энтузиастов где будет BFT, а условный CoinBase - запустит свой симбиот где он будет представлять главного валидатора.

Можно построить гибридную схему где будет как централизующий фактор так и условные "голоса" группы валидаторов этого симбиота. Можно вынести часть логики на хостчейн. Так, к примеру, ваш симбиот может проверяться через контракты некоторого EVM блокчейна - по примеру пары Polygon-Ethereum или других L2 сетей.

Стройте что угодно)

Репозиторий с workflows

На нашем GitHub есть соответствующий репозиторий куда разработчики могут публиковать свои workflow

{% embed url="https://github.com/KLYN74R/Workflows" %}

Вскоре после старта проекта мы опубликуем инструкцию по написанию workflow и как публиковать это в репозиторий

Точка входа workflow на уровне кода

Для большего понимания внутренней кухни поговорим про то, как начинается работа демона когда вы запускаете его.

Пройдёмся прямо по коду для того чтобы и вы понимали.

{% hint style="info" %} Кстати, это можно считать частью нашего разбора кода. Хоть здесь и мы рассмотрим поверхностно, больше и детальней будет в будущем. Демо версию так же можете посмотреть здесь**** {% endhint %}

Первым делом идёт определение полного пути и работа с переменными среды. Ядро так же определяет в каком режиме запущен демон(тестнет/мейннет)

Далее идёт определение основных директорий и путей к ним

Затем ядро грузит конфигурацию в глобальный объект и создает служебные ссылки и директории

Далее мы пропускаем анимации и переходим к важному. Ниже видно как ядро импортирует 2 функции из модуля workflow и вызывает их

На следующем этапе - идёт определение сервисов которые надо запустить в рантайме. Если таких нет, ничего не будет происходить

В конце концов, вызывается ранее импортируемая вторая функция рабочего процесса симбиота. Мы сохранили ссылку на неё на предыдущем этапе. Разработчики workflow сами решают что им запускать в данной функции. Функция запускается в асинхронном режиме

Напоследок, создается сервер который создает глобальную переменную для доступа из под кода workflow. После этого, вызывается import() который и регистрирует роуты которые описываются вашим workflow

Как создаются новые симбиоты

Мы начнём с единой цепочки - первого симбиота. На нём будет сгенерирована и распределена первоначальная эмиссия и из неё будут порождаться другие симбиоты. Наш первоначальный симбиот будет называться kNULL(о чём вы так же узнаете дальше) в честь бога симбиотов в Marvel. Так же, в качестве основного workflow для первого симбиота будет выбран dev_tachyon. О механизме консенсуса Tachyon читайте более детально здесь.

Хоть это и будет происходить в произвольном порядке, но мы всё таки предполагаем, что создание нового симбиота это будет важным событием таким как халвинг или отстрочка бомбы сложности.

Это необходимо для того, чтоб новый симбиот привлёк пользователей, снизив часть нагрузки на другие симбиоты. Так же потенциальные валидаторы или пользователи должны получить какое-то время для подготовки и решения стоит ли им заселять новый симбиот. Ну и необходимо будет провести и другие процедуры, типа добавления такого симбиота в обозреватели, популяризация, настройка вторичных зависимостей и многое другое.

Про общие компоненты для симбиотов

Как упоминалось ранее, есть ряд общих элементов для симбиотов

Сервер

{% embed url="https://github.com/uNetworking/uWebSockets.js" %}

Мы используем данную реализацию сервера. Это популярный, низкоуровневый и быстрый сервер котрый хорошо себя зарекомендовал на частных проектах и тестах. Можете более детельно провести исследование.

Глобальные переменные

Симбиоты так же могут использовать ряд глобальных переменных типа CONFIG для получения данных по конфигурации, PRIVATE_KEY для доступа к приватным ключам, переменные которые указывают на директории и так далее.

{% hint style="info" %} Полный список будет опубликован позже {% endhint %}