🖖Коннекторы
То, что связывает блокчейны
Роль на KLYNTAR
Коннекторы - это модули которые инкапсулируют работу с хостчейнами. Они экспортируют функции для самых разных типов взаимодействия-от простого хранения коммитов на хостчейнах и до более продвинутой логики типа использования zkSNARK и выполнения контрактов. Эти функции потом используются на уровне рабочих процессов для взаимодействия с хостчейнами. Коннекторы обычно распространяются в паках для большего удобства и классификации.
Поскольку это мы должны подстраиваться под функционал других цепочек, то всё что вам нужно для того чтоб написать собственный коннектор - это изучить API, SDK или документацию того хостчейна для которого предназначен коннектор(или группы хостчейнов если там общий интерфейс типа как у EVM совместимых блокчейнов.
Вот как можно схематично обозначить коннектор чтоб у вас было большее понимание происходящего
Конфигурация коннектора и настраиваемые параметры
Так же коннекторы имеют набор необходимых настраиваемых параметров - пара ключей для работы на хостчейне, URL адрес конечной точки(это может быть ваша нода, нода из вашего пула или вообще Node-as-a-Service децентрализованный сервис на KLYNTAR) и ещё некоторые настройки.
Гибкость и глубину настроек определяет сам создатель коннектора.
В рамках определённых стандартов, workflow предоставляет объект HC_CONFIGS который и содержит необходимые конфиги для коннектора. Для того чтоб показать на деле, вот к примеру как выглядит конфигурация одного из workflow который использует набор симбиотов.
Набор настраиваемых параметров определяется в коннекторе. Тут уже всё зависит от того, насколько коннектор крутой и сколько позволяет настроить.
В данном случае используются коннекторы для 3 хостчейнов:
Litecoin
Ethereum
BNB
Всё они из пака dev0. Давайте заглянем внутрь
Стоит так же заметить, что в данном паке представлены не слишком "крутые" коннекторы. Эта группа коннекторов просто сохраняет коммит в хостчейн и затем асинхронно проверят включение
Посмотрим на код коннекторов чтоб вам стало более понятно. Вот коннектор для Litecoin
Внутри функции можно заметить как коннектор получает доступ к своим настройкам через глобальный объект CONFIG.SYMBIOTES[<symbiote>].HC_CONFIGS. Это ровно тот же объект который мы настраивали на уровне конфигурации workflow.
Аналогично и с другими функциями. Вы можете сами исследовать репозиторий для большего понимания того как это работает.
А вот пример EVM совместимого коннектора. Это ещё одно доказательство гибкости KLYNTAR - ведь благодаря 1 коннектору симбиоты могут общаться со всеми EVM совместимыми блокчейнами.
Здесь видно как коннектор использует стандартные параметры для работы с EVM совместимыми блокчейнами. Встречаются знакомые термины типа GAS_LIMIT и GAS_PRICE, вы можете выбрать CHAIN_ID согласно этому ресурсу(для работы с разными сетями) и многое другое.
Внутри же данный коннектор работает следуя документации по Web3 и набора инструментов JS для работы с EVM.
Внутри коннектора
Коннекторы в целом должны быть экспортированным объектом который содержит весь функционал коннектора в своих методах. Так же коннектор может иметь какие-то свои дополнительные зависимости(и поэтому надо будет их подгрузить) или требовать каких-то операций над кодом(что-то скомпилировать внутри модуля и т.д.)
Вот как выглядит общая структура коннектора
Представьте что есть цепочки EVM(Ethereum,Polygon,Avalanche). Для того чтоб сделать так, чтоб они обеспечивали безопасность симбиота KLYNTAR надо написать некоторый коннектор. Что мы можем придумать? Ну самый простой вариант - простое хранения состояния в цепочке как было продемонстрировано выше - без всякой двусторонней логики со смарт-контрактами(особенно если говорить про Bitcoin и подобные где их нет как таковых).
Для такого простого коннектора наверняка надо что-то типа функций setCommit(для того, чтоб какой-то симбиот сохранил коммит) и checkCommit(для того, чтоб проверить факт включения).
В таком случае ваш коннектор может иметь такой вид:
Взаимная работа коннекторов и workflow
Поскольку нам нужен максимум, то как разработчики коннекторов так и workflow должны делать свои модули следуя практике максимально возможной гибкости. Это позволит использовать один и тот же коннектор совершенно разными симбиотами и их workflow.
Использование коннекторов на уровне workflow
В качестве примера можно опять таки привести самый простой workflow(dev_controller). Вот как он использует коннектор в своем коде.
Это функция генерации блоков. В рамках workflow запланировано так, что новый коммит не может быть добавлен если старый ещё не включён в хостчейн. Кроме того, на уровне коннектора определена логика периодического включения. Так к примеру, на Bitcoin и форках(ввиду общего API и похожих структур данных) вы можете установить параметр CONFIRMATIONS и таким образом коммиты будут только через установленные промежутки времени(ввиду того что на Bitcoin происходит коррекция сложности и сеть в любом случае добывает блок приблизительно раз в 10 минут). Но это лишь пример, другие коннекторы могут быть более функциональны и предоставлять другие класcные возможности.
Точка входа в функцию https://github.com/KLYN74R/KlyntarCore/blob/0cd166e7790e9ddeac9d3d3b8ce069689bdba13b/KLY_Workflows/dev_controller/life.js#L137 Вот тут вот как раз для гибкости разработчик workflow и мог бы придумать что-то для workflow. К примеру, блок бы сгенерировался, если б достиг некоторого порога ставок с мультиподписями и так далее
Эта страница ещё будет обновляться так как тема коннекторов очень большая и захватывающая
Last updated