🤞Кроссчейновые бесшовные смарт-контракты
Важная фича KLYNTAR VM
Кроссчейновые смарт контракты с помощью KLYNTAR VM
Вот бы было здорово писать смарт-контракты с кроссчейн логикой. Когда часть вашего контракта выполняется на Polygon, часть на KLYNTAR и ещё одна - на условном Litecoin(да, да, мы сделаем так, что возможно будет использовать даже цепочки без смарт-контрактов).
Поскольку узлы KLYNTAR в рамках взаимодействий симбиот-хостчейн так или иначе взаимодействуют с хостчейнами, то можно было бы использовать эту связь для выполнения кроссчейн логики. Кроме того, наверняка у узлов которые работают на определённом симбиоте имеются ноды или по крайней мере API для работы с хостчейнами, а значит применять их для смарт-контрактов не составит труда.
Ещё одна отсылка к гибкости симбиотической структуры
Каждый симбиот будет предоставлять свой доступ к разным сетям. Именно поэтому при выборе вы должны проверять поддерживает ли симбиот нужные вам сети. Самим же операторам нод определённого симбиота как раз таки и позволено выбирать баланс между количеством хостчейнов, их набором и т.д.
Если один симбиот будет предоставлять API для работы на менее популярных хостчейнах чем другой, то доход нод на этом может быть меньше и симбиот потеряет валидаторов и узлы. Аналогично и в другую сторону - если симбиот будет слишком "дорогим" для запуска, то и отсюда уйдут люди. И хоть это не особо критично благодаря Мутуализму всё же рекомендуется соблюдать баланс.
Пример
Давайте предположим что вы хотите написать ончейн кроссчейновый смарт-контракт на KLYNTAR между сетями которые уже были в примере - Polygon(EVM логика), KLYNTAR(основная логика и кроссчейн связь) и Litecoin.
Пусть наше приложение - это что-то типа обменника с дополнительной логикой(не просто обмен токенами, но ещё и выполнение каких-то функций). Пользователи могут вносить токены и монеты на контракт Polygon и при этом отправлять монеты на соответствующие адреса на Litecoin для проведения определённых операций смарт-контракта(как на Polygon так и на KLYNTAR). В рамках нашего воображаемого контракта мы напишем крайне простое приложение, что-то типа HelloWorld, но с тематикой описанной выше. Пусть у нас будет такой функционал:
Polygon
На Polygon в рамках контракта будет определено 2 функции:
spendTokens Функция которая будет вызываться извне(то бишь направление => Polygon) и которая на основании входящих данных позволяет пользователю что-то совершать с токенами
getDatа Возвращает какие-то данные про адрес, необходимые для смарт-контракта на KLYNTAR
KLYNTAR
Мы приведём пример на AssemblyScript. Синтаксис похож на TypeScript, но даже если вы не знакомы с ним, то в целом должно быть просто и понятно. Так же мы в будущем представим и другие примеры
На KLYNTAR в рамках WASM контракта будут определены такие функции:
performLitecoinPolygonLogic Функция которая получает на вход адрес вызывающего и данные по API вызову данных из Litecoin. Возвращает результат операции
performPolygonLitecoinLogic Тут похожим образом, но только до этой функции KLYNTAR получает данные из Polygon(путём вызова getData из контракта Polygon который мы описали выше) и только тогда происходит вызов данной функции
Litecoin
Тут интересней, ведь Litecoin, будучи форком Bitcoin, не имеет традиционных смарт-контрактов на Тьюринг полном языке и оперирует лишь примитивными опкодами. Но нам и не нужно от него большего.
Для таких языков KLYNTAR будет предоставлять специальные API, так что при написании своих смарт-контрактов, вы будете использовать именно их.
В этом нет проблемы потому что если нет возможности выполнения смарт-контрактов, значит все возможности криптовалюты и сводятся к простым транзакциям. Это означает что всё что можно выжать из такой криптовалюты - это стандартные вызовы типа getTransaction(txID), getInputs(address)(если речь идёт про криптовалюты с UTXO типом) и так далее.
Хорошая новость так же в том, что можно создать очень большой набор таких функций с самым разным функционалом - где-то можно получить чистый массив выходов транзакций, проверить была ли это TAPROOT транзакция, отфильтровать и получить только время транзакции и многое другое.
Теперь поговорим детальней про выполнение.
Шаг первый - пишем смарт-контракт на Polygon и деплоим в сеть
Первое что вы делаете - пишите логику контракта для Polygon. Мы выше описали необходимые функции и их сигнатуры, функционал опущен для простоты. Затем вы получаете байт-код и ABI который необходим вам для работы с контрактом. Вы деплоите контракт в Polygon и храните ABI.
Так же не забывайте про открытый исходный код если ваш проект требует того
Шаг второй - пишем смарт-контракт на KLYNTAR и деплоим в сеть
Аналогично, вы пишете часть для работы с KLYNTAR. В примере выше мы использовали AssemblyScript. Сигнатуры функции и общий принцип работы должен быть понятным. Вы компилируете контракт в .wasm и готовитесь к шагу 3.
Шаг третий - связывание
На этом этапе у вас есть
Контракт на Polygon
Его ABI(вы должны иметь его локально)
Написанный контракт на KLYNTAR и его .wasm байткод
Теперь нам необходимо связать всё так, чтобы всё работало. Для этого, перед тем как деплоить всё в сеть KLYNTAR надо будет составить что-то типа карты вызовов благодаря которой всё будет работать как единый организм.
Ноды KLYNTAR должны просто знать что если пришёл вызов какого-то контракта X, то необходимо просто открыть его карту вызовов и посмотреть что нам делать дальше. Для нашего с вами приложения такая карта вызовов может иметь такой вид
Карта вызовов(call map) - это по сути своей JSON объект в свойствах которого определены имена функций смарт-контракта KLYNTAR. Значениями этих свойств являются массивы которые содержат объекты что описывают необходимый вызов функций ПЕРЕД этой. После того, как массив закончится вызывается данная функция с параметрами которые были получены в результате вызова последней подфункции в этой цепи.
В общем виде карта вызовов может выглядеть как-то так.
Для функций, которые не будут требовать взаимодействия с другими сетями необязательно составлять и добавлять в карту вызовов.
Возвращаемся к нашему приложению
Итак, после того, как вы составили карту, вы начинаете деплой в KLYNTAR. Нужно отправить
ABI для Polygon контракта
.wasm модуль контракта KLYNTAR
Карту вызовов
Всё это сохранится под идентификатором BLAKE3 функции и вы сможете начать взаимодействовать с контрактом. Напомню, что наша карта имеет такой вид
Предположим что в рамках логики было установлено так, что на Litecoin должна пройти какая-то транзакция и после этого можно запускать код на KLYNTAR. Условный отправитель формирует событие на KLYNTAR
Ниже будет представлен псевдокод. Настоящий формат данных может отличатся от того, что представлено здесь
Это отправляется в сеть KLYNTAR на соответствующий симбиот и происходит дальнейшее выполнение.
Получив это, ноды(или первичный валидатор который будет выполнять это) берёт идентификатор контракта и достает карту вызовов из хранилища.
Поскольку функция performLitecoinPolygonLogic присутствует там, то происходит следующее:
Имея такой вот конвейер для данной функции
Нода понимает что тут речь идёт про API Litecoin и на основе полученных параметров вызывает функцию getTransaction передавая туда массив полученный из вызова KLYNTAR контракта
После этого, предположим что функция вернула нам транзакцию в hex виде
Затем смотрим на карту вызовов дальше
Поскольку тут больше ничего нет, то теперь вызываем саму функцию performLitecoinPolygonLogic
Напомним, что ее сигнатура имеет вид
Поскольку на прошлом шаге мы получили транзакцию в hex виде, то она и передается в эту функцию в качестве параметра. Происходит вызов
Вот собственно и всё. Хоть мы и не затестили функцию для работы с Polygon, но в целом принцип такой же. Так же можно и усложнять и проводить более сложные операции.
Что можно ещё дополнить
Возможности тут безграничные - можно будет строить разного рода адаптеры на данные, настраивать собственную комиссионную политику, включать много цепей в 1 вызов KLYNTAR контракта, узлы KLYNTAR смогут не только получать данные и проверять, но и при наличии, например баланса на Polygon проводить "платные" вызовы и так далее. Мы будем постоянно держать вас в курсе наших разработок и прогресса. Предлагайте свои идеи и помогайте решать проблемы 👍
Перспективы
Благодаря симбиотической структуре и принципу шардинга по умолчанию, KLYNTAR позволяет вам выбирать нужные для вас симбиоты. Благодаря релизу Mutualism вы, при необходимости сможете платить нодам других симбиотов чтоб и они проверяли ваши контракты. Вы сможете вручную назначать только избранных валидаторов которым будет позволено выполнять ваши контракты, а благодаря тому, что KLYNTAR будет очень социальным(это можно понять по ссылкам даже на уровне конфигурации нод где вы можете поделиться своим сайтом, почтой или способом связаться с вами) вы сможете легко развязывать нужные вам задачи.
Теперь ваши токены будут полагаться на безопасность KLYNTAR - а значит на безопасность всей индустрии, ваши пользователи получат доступ к передовой криптографии, будут использовать максимальные скорости всей индустрии благодаря SpookyAction, фантомным блокам, тотальной асинхронности и прочему.
Следите за KLYNTAR и, если вам не трудно, помогите нам отправив донат на наши адреса
Last updated