January 26, 2022

Про кроссчейн с модулями в программах Нод валидаторов или майнеров

Часть 1, Часть 2

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

Сейчас это более подробно и рассмотрим...

Схема работы:

1. Валидаторы[1] или майнеры устанавливают модуль в программу своей Ноды[3].

Модуль - специальный код, который расширяет функционал. Он обладает достаточной автономией, хоть и взаимодействует с другим функционалом ПО.

2. Этот модуль создаёт специальный адрес, к которому имеют доступ только владельцы Нод, находящиеся в топе.

3. Пользователь переводит туда свои токены.

В случае Ethereum это может быть ETH, USDT, USDC, WBTC или что угодно иное, поддерживаемое модулем...

В BTC - сам Биткоин или USDT Umny.

В сообщении к транзакции указывается, что хочет получить пользователь.

Стандарт может быть любым, но общим для всех.

Например, для перевода BTC в Ethereum пользователь может указать:

{action: "send_to", blockchain: 1, address: "0x..."}

Где 1 - id блокчейна.

(список id указывается в модуле)

4. Когда эта транзакция подтверждается, пользователь (сервис) получает ZK доказательство этого.

5. Далее оно отправляется в виде транзакции Ethereum на адрес местного модуля.

Модуль принимает это, после чего выпускает BTC.

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

Для этого они могут использовать разные методы:

свои API[4] Ноды в других сетях или сторонние.

То же самое происходит с обратным действием или с передачей в другие блокчейны.

При этом, может быть не только отправка, но и:

1. Кредитование:

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

2. Иные действия.

Могут поддерживаться не все подряд блокчейны. Даже скорее будет иначе:

Поддержка лишь интересных / схожих / популярных.

Но никто не мешает сделать проекты, что будут проходить по более длинному пути 😊.

Приведу пример.

Допустим, вы хотите передать свои BTC в Aurora, а он отсутствует в модуле Bitcoin Нод:

1. Указывается действие отправки с указанием в сети Ethereum адреса кошелька модуля.

2. Также вводится новый параметр memo, где указывается дальнейшее действие.

Получается следующая конструкция:

{action: "send_to", blockchain: 1, address: "0x...", memo: "{action: "send_to", blockchain: 5, address: \"0x...\"}"}.

Поясняю:

То, что вне memo - перевод из BTC в Ethereum;

То, что в memo - сразу же информация для модуля Нод Эфира о том, что передача в блокчейн Aurora (id 5).

Если же транзакция становится дорогой или много символов становится, сначала указывается адрес пользователя в Эфире, на него производится перевод, а затем производится отправка транзакции в Aurora (по шагам, без memo).

Порядок же следующий:

1. Отправка транзакции с суммой и указанием адреса модуля Ethereum;

2. Получение доказательства и отправка его на адрес модуля в Ethereum;

3. Принятие транзакции модулем Эфира и создание BTC с последующей выдачей доказательства отправки в Aurora;

4. Идём в Aurora и отправляем транзакцию на адрес местного модуля, чтоб выпустить BTC на ваш адрес...

Риски варианта:

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

Если они есть, не принимать обновления с изменениями, которые приведут к неработоспособности...

2. Риски самих блокчейнов.

3. Приложение из-за ошибок или по иным причинам может не завершить выполнять действия, например, не отправить транзакцию с доказательством выполнения действия в блокчейне-источнике...

Минусом также является стоимость транзакций:

Отправки с указанием сообщений к транзакциям дороже обычных...

Но иначе никак не сообщить детали модулю...

P. S.

Выше написанное является лишь моим мнением о том, как всё может развиваться в ближайшие 5-10 лет, а может и больше.

Также вполне вероятно, что тонкости будут отличаться, поскольку мой вариант окажется не надёжным или ошибочным...

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

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

Поэтому, если у вас есть мысли, идеи, предложения, указания на ошибки, пишите в чат @blind_dev_chat - хочется по обсуждать вектора развития в данном направлении.

Тем более, что за дельные сообщения я награждаю #VIZ или другими криптовалютами.

Благодарю за внимание. Всем хорошего дня или вечера.

Примечания:

1. Валидатор - пользователь, который согласился собирать транзакции в блоки и подписывать их.

Ранжируются в соответствии с алгоритмами консенсуса, например, Dpos.

2. Нода - программа, выполняющая действия из пункта 1.

3. API - специальные адреса для доступа разработчиков к функционалу.

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

Остальные термины рассмотрены в первых двух частях:
Часть 1, Часть 2