| description | cover | coverY |
|---|---|---|
Сердце любого симбиота |
../../../.gitbook/assets/951080b614db5517e5d24e55c46dca05.gif |
0 |
Каждый известный вам блокчейн проект работает следуя сценарию который описали программисты. Некоторые используют PoW консенсус(Bitcoin,Monero,ETC), некоторые полагаются на BFT модификации(Avalanche,Fantom) или PoS(Ethereum 2.0,Cardano).
При работе одни используют VDF или мультиподписи, обязательства Педерсона и zkSNARK. Все разные. Каждый хорош чем то.
Чтобы не сковывать разработчиков и пользователей мы позволяем сделать так, чтоб каждый симбиот мог работать следуя своим правилам, комиссионной политике и так далее. Это дарит возможности пользователям использовать нужные им симбиоты в зависимости от необходимых задач, а разработчикам позволяет создавать реальных монстров в мире блокчейнов.
Ранее мы говорили о том, что симбиоты могут самостоятельно создавать или использовать готовые шаблоны рабочих процессов.
Большая гибкость позволяет вам настроить внутри workflow разного рода необходимые взаимодействия - связь с API, использование коннекторов, общение с другими нодами и так далее. Так же здесь вам стоит решать другие проблемы - кэширование, обработка системных сигналов, хранение данных, генерация снепшотов, выбор валидаторов и другие проблемы характерные для блокчейнов.
Используйте всё что придумаете )
Приведём в пример первоначальный workflow dev_controller. На уровне его кода определено что он имеет главного валидатора и при этом, позволяет делать ставки на другие узлы которые так же могут генерировать блоки. Этот workflow и представлен в примерах изображений ранее. Вы могли его видеть на странице Симбиоты.
%20(3).png)
Здесь как раз таки и видно что он как бы главный(большой чёрный сервер). Не переживайте, это никак не повлияет на децентрализацию даже для этого workflow, не смотря на то, что у нас будут и другие вариации рабочих процессов(например, супер децентрализованный dev_tachyon на основе BFT).
В коде вы могли бы заметить два типа блоков. Это определено на уровне этого workflow и предназначено для соответствующих ролей - главного валидатора Controller(и ControllerBlock) и нод которые так же могут генерировать блоки InstantGenerators(для них - InstantBlocks).
%20(2).png)
В процессе работы контроллер собирает все эти InstantBlocks( которые содержат транзакции, вызовы смарт контрактов и так далее) в ControllerBlock и отправляет коммит на хостчейны или выполняет другую логику через коннекторы(к примеру, меняет состояние контракта). Вот как выглядит этот этап
На уровне коннектора определено простое включение(без дополнительной логики). Так же контроллер не имеет права тратить свою ставку между коммитами. Аналогичное правило работает и для InstantGenerators - они могут подписывать единственную верную цепочку полученную от контроллера и затем проверить что именно она была включена на хостчейн.
Если же нет, то можно предоставить доказательство другим симбиотами и контролллер лишиться ставки. При этом, если ваша транзакция попала в неоткатный блок(с зелёной рамкой), то всё в порядке - теперь на страже неоткатности стоят хостчейны и другие симбиоты.
Только после очередного коммита можно будет забрать ставку и вы сможете убедиться что ваша транзакция была неоткатной
Фантомные блоки
{% hint style="info" %} Фантомные блоки будут присутствовать и в других workflow KLYNTAR {% endhint %}
Важной особенностью каждого workflow являются его фичи. Так к примеру workflow dev_controller имеет параллельные потоки проверки и генерации блоков.
Помимо того, что это очень быстрый workflow, он обладает важной фичей - фантомными блоками.
Фантомные блоки позволяют не генерировать блоки определённого размера раз на промежуток времени, а позволяют контроллеру или текущему валидатору(если это не dev_controller рабочий процесс) выпускать в мир сразу ВСЕ транзакции которые у него есть. Позже, асинхронный поток проверки дойдёт и до этих блоков и проведёт изменения состояния.
Таким образом, не удивляйтесь если только что был блок 100 000, а через 2 секунды появляется ещё 100 блоков.
Давайте проведём визуализацию. Первое - рассмотрим потоки верификации и генерации.
.png)
Зелёные - это блоки которые нода уже успела проверить, пунктирные - это те которые были сгенерированы за один раз, спустя пару секунд после предыдущей партии.
В таком случае, валидаторы и подписанты подписывают блок с максимальной высотой и его хэш - в данном случае это 119 блок.
Благодаря этому, моментально формируется развитие цепочки симбиота. Не важно, что не проверены блоки ранее, важно утвердить единственную цепочку. С этого момента и начинаются ещё большие интересности
Преддоверие к валидности
Поскольку мы не проверили блоки ранее(начиная со 110го), мы не можем знать какие текущие балансы аккаунтов и какие состояния смарт-контрактов. Это потому, что потенциальный атакующий может отправлять транзакции разным узлам, так что если даже они б и вели какой-то локальный счёт, всё равно без полной проверки невозможно убедиться в текущем состоянии.
В этом случае - мы пользуемся определённым преддоверием. Мы верим нашим пользователям и как бы говорим:
Мы позволяем вам проводить транзакции асинхронно и чудовищно быстро, но будьте честными с сетью. В противном случае, вы лишитесь части своих монет
Давайте представим, что в блоке 109 который уже валидирован пользователь X заморозил часть своей ставки и как-бы сказал
Я ставлю свои 100 KLY на то, что в следующих 1000 блоках не буду нарушать ничего и все мои транзакции будут тратить не больше чем я имею, иметь правильный nonce и в целом будут валидными
Если на протяжении блоков 110 - 119 будет замечена хоть одна неправильная транзакция со стороны адреса X, то сеть лишит его 100 KLY
Локальные наблюдения
Благодаря социальному взаимодействию можно минимизировать риск невалидных транзакций. Так к примеру, благодаря разным плагинам на KLYNTAR вы сможете настроить прием транзакций от условного Binance или CoinBase. Вы будете предполагать что вряд-ли таким биржам выгодно проводить атаки против KLYNTAR и спамить невалидными транзакциями, так что примите их транзакцию и поместите в блок.
Так же, ноды могут вести свои локальные списки кто сколько потратил(и таким образом отклонять невалидные транзакции ещё на этапе приёма их на сервере) и пользоваться другими преимуществами плагинов и фич рабочих процессов
Заключительный этап - проверка на кошельках
Ещё одним преимуществом является то, что ваши кошельки(если они будут поддерживать такой функционал) могут обрабатывать платежи от других адресов моментально благодаря фантомным блокам.
Обратимся к нашему примеру - пусть вы ожидаете от какого-то клиента Bob оплату его заказа в вашем интернет-магазине. Вы дали ему свой адрес
FWZbuAkX6hAbpg5c9QixUxwjiWdSHMSLPBqHM1hoh8mc
для того чтоб он произвёл оплату. При этом, 109 блок уже проверен и вы знаете что у Боба там 100 KLY монеток. Ваш товар пусть стоит 10 KLY.
После того, как сеть произведёт моментально ещё 10 блоков(110-119), ваш кошелёк(или специализированный API на бэкенде вашего магазина) подгрузит эти блоки и быстренько проверит наличие необходимой транзакции. При этом, вам не стоит даже проверять другие транзакции - вы просто берёте только те, где Боб отправитель и проверяете. При этом, у вас уже на руках мультиподпись валидаторов мол
119 блок с хэшем aaaaa.... - уже часть блокчейна
Если вы находите валидную транзакцию в этой серии блоков от Боба в уплату за ваш товар, то всё отлично - можете отправлять товар. Предположим что вы нашли ее в 116 блоке. Теперь у вас на руках есть уверенность в том, что транзакция Боба - валидная и что 119 блок с нужным хэшем вошёл в цепочку симбиота. И это при том, что вы ещё не проверяли другие транзакции и блоки 110-119 на вашей ноде по прежнему не проверены. В этом вся магия)
Конфигурация
Да, к гибкости данного workflow можно отнести ещё и конфигурацию - вы можете найти её здесь:
{% embed url="https://github.com/KLYN74R/KlyntarCore/blob/main/ANTIVENOM/CONFIGS/symbiotes.json" %}
Тут вы можете гибко настраивать время генерации блока, останавливать и запускать потоки генерации и верификации блоков, настраивать время опроса новых блоков, настраивать TTL сервера, выделять отдельные конечные точки для подгрузки блоков оттуда(это может быть какой-то CDN к примеру, ведь блоки - статический контент) и многое другое. Рекомендуем разработчикам workflow так же делать свои конфигурации достаточно подробными.
Кто угодно на KLYNTAR сможет создать собственный workflow при наличии необходимых навыков(программирования, знаний в области криптографии и понимания работы блокчейнов). Поскольку в рамках workflow вы фактически и описываете то как всё работает(генерация блоков, выбор/смена валидаторов, использования ресурсов других сетей, взаимодействие с хостчейнами), то на вас ложиться задача создания реально классного и нужного workflow - в противном случае никто не будет его использовать.
Мы предполагаем наличие нескольких востребованных workflow. Какой-то рабочий процесс будет хорош своей скоростью, какой-то безопасностью, третий будет использовать механизмы с нулевым разглашением, ещё один будет использовать какие-то свои фишки.
Таким образом мы позволяем новым симбиотам использовать лучшие доступные механизмы для разных потребностей. А пользователи смогут выбирать симбиота под себя в зависимости от того, что нужно им.
Для того, чтоб вам было легче создать собственный workflow существует dev_helloworld. Это рабочий процесс созданный в качестве шаблона. Он ничего не делает кроме как выводит в консоль Hello World from dev_helloworld !!! в заданный период времени.
На GitHub в этом репозитории лежит README который включает необходимые подсказки для создания собственного рабочего процесса.
%20(4).png)
{% embed url="https://github.com/KLYN74R/KlyntarCore/tree/main/KLY_Workflows/dev_helloworld" %}
Рабочие процессы поражают своим многообразием и возможностями. Мы надеемся, что разработчики оценят наши идеи и мы вместе будем создавать много классных вещей для индустрии