Проект, который в начале соединял Cosmos экосистему и EVM через Celestia и Forma chain, а потом расширил и до других сетей.

Фишкой является возможность самостоятельного добавления сетей через развёртывание смарт-контрактов Hyperlane и запуск ретрансляторов

Ссылку на LinkedIn нашёл через поиск, а не на их сайте или в документации...Да и компания называется иначе...

LinkedIn Abacus Works:

543 отслеживающих, последняя публикация 2 месяца назад получила 10 реакций и 2 репоста.Предыдущая была опубликована тоже 2 месяца назад. Получила 10 реакций и 2 репоста.

Прикольно, что у них в профиле есть вокансии: желающие могут их посмотреть.

Интересно, что в октябре 2022 у них было 8 сотрудников, а в октябре 2024 - 20.

Люди компании:

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

Gillian Nguyen:

9566 отслеживающих. Последняя публикация 6 дней назад. Она получила 12 реакций.Предыдущая была опубликована неделю назад, и получила 9 реакций.

Опыт работы:

• Lead Technical Recruiter в Abacus Works с февраля 2024

• Senior Technical Recruiter в Branch с января по декабрь 2023 (удалённая работа)

• В Meta: Engineering Leadership Talent - Production Engineering с апреля 2020 по апрель 2022, Engineering Leadership Talent - SWE (Software Engineering) с марта 2022 по начало 2023

• Technical Recruiter в dYdX с декабря 2018 по апрель 2020

• Talent Manager в Blockchain Works с января по октябрь 2018

Образование:

• University of Toronto: Bachelor's degree, Economics

• George Brown College: Design and Applied Arts

Навыки:

• Staffing, Talent Recognition - Talent Manager в компании Blockchain Works, 1 подтверждение

• Startup Development - Lead Technical Recruiter в компании Abacus Works, 1 подтверждение

• Onboarding - Senior Technical Recruiter в компании Branch, 1 подтверждение

• Sourcing - Опыт работы (3) в компании Abacus Works и еще в 2 компаниях, 1 подтверждение

• Talent Mapping - Опыт работы (3) в компании Branch и еще в 2 компаниях

• Technical Recruiting - Опыт работы (4) в компании Abacus Works и еще в 3 компаниях, 4 подтверждения

• Internet Recruiting - 27 подтверждений

• Consulting - 14 подтверждений

• Talent Acquisition - Опыт работы (2) в компании Branch и еще в 1 компании, 12 подтверждений

• Financial Services - 6 подтверждений

• HR Consulting - 10 подтверждений

• Recruiting - 18 подтверждений

• И т. д. (всего 28 навыков).

Eda Akturk:

829 отслеживающих. Последняя публикация была 1 месяц назад. Она получила 103 реакций и 11 комментариев. Классно, что про компанию пост.Предпоследняя публикация была размещена 4 месяца назад. Она получила 15 реакций.

Опыт работы:

• Developer Advocate в Abacus Works с сентября 2024

• Technology and Innovation Consultant в The World Bank с мая 2023 по июнь 2024 (контракт)

• Developer Relations  в Ethereum Foundation с августа 2022 по апрель 2023 (контракт, удалённая работа)

• В Cisco: Associate System Engineer с августа 2019 по июль 2020, Technical Solutions Specialist с августа 2020 по январь 2022

• В GE Healthcare: EGM/SHS Service Analytics Intern с августа 2017 по февраль 2018 (Стажировка), EGM Service Analytics Specialist с февраля 2018 по июль 2019

• В Koç University: Exchange Student Mentor с сентября 2016 по июль 2017, Exchange Student Board Mentor с августа 2017 по июнь 2018

• Business Analyst Intern  в ASEE в июле 2017

• Software Developer Intern - Microsoft Turkey Summer Camp в августе 2016

Образование:

Koç Üniversitesi: Bachelor of Science - BS, Computer Engineering с 2014 по 2018, Bachelor of Arts - BA, Economics с 2016 по 2019

Навыки:

• Microsoft Office - Подтверждения навыков от участника Abdulla AlHelou, который является специалистом в этой области, Подтверждения навыков от 2 коллег по компании Cisco, 9 подтверждений

• Customer Service, Microsoft Excel - Подтверждения навыков от 2 коллег по компании Koç Üniversitesi, 2 подтверждения

• agement - 2 подтверждения

• Project Management - 6 подтверждений

• Microsoft Word, PowerPoint, Research, Public Speaking - 2 подтверждения

• Leadership - 7 подтверждений

• Computer Engineering - 5 подтверждений

• Cisco Certified

• Amazon Web Services (AWS) - Оценка навыков LinkedIn успешно выполнена

• Python (Programming Language)

Начну с пустых профилей...

Works Abacus:

0 отслеживающих. Ни навыков, а в опыте работы только должность в Hyperlane: управляющий директор... Есть небольшие сомнения, что это тот, но другого с похожим описанием аккаунта в поиске не нашёл...

И второй - Chan Lee:

1 отслеживающий, в опыте работы только компания проекта с должностью исполнительный директор, больше ничего нет...

Avi Atkin:

3569 отслеживающих. Последняя публикация две недели назад. Она получила 16 реакций и 3 комментария. Статья была не про Hyperlane, но про блокчейн сферу...

Опыт работы:

• В Abacus Works: Product Manager с июля 2023 по август 2024, Product Lead, Ecosystem Growth с августа по октябрь 2024

• Product Manager в 3Box Labs с апреля 2022 по июль 2023

• Product Manager, Autonomous Vehicles в Ford Motor Company с ноября 2017 по август 2021

• 2016 Venture for America Fellow в Venture For America с июля 2016 по июнь 2018

• Data Lead в Roadtrippers с августа 2016 по август 2017

Образование:

Baruch College: Bachelor of Business Administration (B.B.A.), Computer Information Systems

Навыки (всего 31 - покажу с подтверждениями):

• Product Design - 7 подтверждений

• User Experience - 4 подтверждения

• Social Media - 67 подтверждений

• Marketing Strategy, Social Entrepreneurship - 1 подтверждение

• Strategic Planning - 18 подтверждений

• Market Research - 10 подтверждений

• Event Planning - 20 подтверждений

• Writing - 4 подтверждения

• Financial Modeling - 1 подтверждение

• WordPress - 16 подтверждений

• И другие (все равно много получается...)

Connor McEwen:

1421 отслеживающий. Последняя публикация 6 месяцев назад, которая получила 103 реакции, 10 комментариев и 2 репоста.

Опыт работы:

• VP of Engineering (Вице-президент по инжинирингу) в Abacus Works с мая 2024

• Director of Engineering в Uniswap Labs с августа 2021 по май 2024

• Partner, Engineering в cLabs с марта 2018 по август 2021

• Самозанятый Консультант по разработке программного обеспечения с марта 2017 по март 2018

• Lead Engineer, Emerging Products в GoDaddy с декабря 2015 по май 2017

• Software Engineer в Wildcard Inc с сентября 2014 по декабрь 2015

• Boston Investment Team в Dorm Room Fund с октября 2013 по май 2014

• Business Analyst в Boston University Office of Technology Development с июня 2013 по май 2014

• Co-Founder в Credport с мая 2012 по май 2013

• Research Assistant в Boston University Multimedia Communications Laboratory с февраля 2011 по январь 2012.

Образование:

Boston University: Bachelor of Science (BS), Computer Engineering2010 - 2014

Навыки:

• Start-ups - Подтверждения навыков от участника Rene Reinsberg, который является специалистом в этой области, Подтверждения навыков от 2 коллег по компании Wildcard Inc, 21 подтверждение

• Mobile Applications - Подтверждения навыков от участника Michael Healy 麦克李, который является специалистом в этой области, Подтверждения навыков от 3 коллег по компании Boston University, 16 подтверждений

• Mobile Devices - Подтверждения навыков от 2 коллег по компании Boston University, 15 подтверждений

• Entrepreneurship - 12 подтверждений

• Product Management, Product Development, Software Development - 7 подтверждений

• И другие... Всего 29.

Anthony Spezzano:

1056 отслеживающих. Последняя публикация вышла 1 день назад, и получила 3 реакции, 1 комментарий и 1 репост.Предыдущая была опубликована две недели назад. Она получила 9 реакций.

Опыт работы:

• Head of Business Development в Abacus Worksс августа 2023

• В Figment: Senior Protocol Analyst с мая по декабрь 2022, Principal Portfolio Analyst с декабря 2022 по август 2023

• Business Process Consultant в TD с марта 2021 по апрель 2022

• Risk Management Analyst в TD Securities с июля 2017 по март 2021

Образование:

York University: Bachelor's degree, Cognitive Science

Навыки:

• Personal Finance - 7 подтверждений

• Computer Proficiency - 8 подтверждений

• First Aid - 6 подтверждений

• CPR Certified - 4 подтверждения

• Personal Budgeting - 2 подтверждения

• И другие (всего 28).

Также я из статьи про инвестиции в проект узнал имена и фамилии сооснователей: рассмотрим их.

Asa Oines:

374 отслеживающих. Публикаций нет.

Опыт работы:

• Co-Founder в Abacus Works с августа 2022 по сентябрь 2023 (получается возможно уже не работает тут)

• Engineering в cLabs с марта 2018 по декабрь 2021

• Software Engineer в Google с августа 2015 по март 2018

• Software Engineering Intern в Google с июня по август 2014

• Hardware Engineering Intern в Apple с июня по август 2013

• Software Engineering Intern в Google с июня по август 2012

Образование:

1. Massachusetts Institute of Technology: Master of Engineering - MEng, Computer Science с 2014 по 2015

2. Massachusetts Institute of Technology: Bachelor of Science - BS, Computer Science с 2010 по 2014

Навыки не указаны.

Jon Kol:

1070 отслеживающих, публикаций нет.

Опыт работы:

• Chief Executive Officer в Abacus Works с марта 2022

• Managing Director в Galaxy с сентября 2019 по март 2022

• Investment Team в Passport Capital с февраля 2018 по сентябрь 2019

• Fixed Income Analyst в Morgan Stanley с июня 2016 по февраль 2018

• Summer Analyst в Morgan Stanley с июня по август 2015

• Corporal в Israel Defense Forces с 2008 по 2010

Образование:

University of California, Berkeley: Bachelor's degree, Economics

Навыки:

• Research - 3 подтверждения

• Valuation, Data Analysis - 2 подтверждения

• Microsoft Excel, Public Speaking - без подтверждений

• Municipal Bonds, Corporate Bonds, Fixed Income - 1 подтверждение

Nam Chu Hoai:

724 отслеживающих. Последняя публикация 8 месяцев назад с 19 реакциями и 3 комментариямиПредпоследняя - 2 года назад: 128 реакций и 17 комментариев.

Опыт работы:

• Co-Founder / CTO в Abacus Works с апреля 2022

• Software Engineer в cLabs с августа 2018 по март 2022

• Software Engineer в Wellframe с июня 2014 по январь 2018

• GEIR в Venture Development Center at UMass Boston с сентября 2016 по май 2017

• Фрилансером был Fullstack Web Developer с июня 2014 по август 2015

• И другое (всего - 12).

Образование:

Boston University: Bachelor of Arts (B.A.), Computer Science2010 - 2014

Навыки (всего 30 - покажу лишь часть):

• Entrepreneurship - Подтверждения навыков от участника Stefan Jørgensen, который является специалистом в этой области, Подтверждения навыков от 3 коллег по компании Wellframe, 10 подтверждений

• Web Development - Подтверждения навыков от 2 коллег по компании Wellframe, 8 подтверждений

• HTML 5, Venture Capital - 3 подтверждения

• Programming - 2 подтверждения

• И другие (всего 30)

У большинства из представленных хороший опыт и навыки, а некоторые работали в известных компаниях, например, Meta и Microsoft.

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

X (twitter) @hyperlane:

77,4 тысяч читателей, 2499 постов.

Последний пост был 14 часов назад. Он получил 23 ответа, 110 репостов, 380 лайков, 16844 просмотров.Предыдущий вне треда - 18 часов назад. Получил 19 ответов, 112 репоста, 480 лайков и 75015 просмотров.

Аудит по tweetscout:

Score 1072, уровень 4 (Significant).

Проекты: DEGEN NEWS, Circle, Alchemy, Layer3, CC2, Everclear (prev Connext), Fuel, L2BEAT, Gelato, WOO X, Moonbeam Network и другие...

Венчурный капитал: loomdart - Holy War Arc, eGirl Capital 仙女資本, DeFi Dad ⟠ defidad.eth, Fourth Revolution Capital, Jesse Walden, Variant и другие...

Афеллированные аккаунты:

Участники команды и другие...

Discord:

В анонсах последний пост сегодня.

В основном чате активность есть, на вопросы отвечают, и корректно:

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

В Русском чате активность тоже есть, да и на мой вопрос ответили:

История ушла вперёд, поэтому показываю ответ на свой вопрос отдельно:

Тикетов здесь нет, но есть суппорт-форум:

Оценка 4 из 5: LinkedIn конечно на сайте нет, да и ссылки не у всех есть, но через поиск можно найти сотрудников, и у них хороший опыт работы с навыками, поэтому лишь минус один балл.

Hyperlane — это первая в своем роде безразрешительная (permissionless) интероперабельная платформа, которая предоставляет возможность для соединения различных блокчейнов в одном пространстве. Она позволяет разработчикам смарт-контрактов обмениваться произвольными данными между сетями, создавая единую экосистему для межцепочных приложений (interchain applications), доступных пользователям на любой поддерживаемой блокчейн-платформе.

Основная концепция Hyperlane — это создание гибкого и настраиваемого интероперабельного фреймворка, который охватывает более 70 различных блокчейнов и поддерживает свыше 5 виртуальных машин (VMs). Это позволяет проекту соединять любые чейны без необходимости ожидания поддержки от сторонних провайдеров моста, так как Hyperlane предоставляет возможность самостоятельного развертывания (DIY) на любом блокчейне. Такой подход обеспечивает масштабируемость и значительно ускоряет процесс интеграции новых сетей.

Hyperlane реализует модульную архитектуру безопасности, что позволяет разработчикам выбрать подходящий модуль безопасности для своих нужд с помощью Interchain Security Modules (ISMs). Эта система позволяет применять свои валидаторы, устанавливать лимиты по скорости передачи данных и задействовать экономическую безопасность на сумму более $5 миллиардов через Hyperlane AVS. Доступность различных моделей безопасности делает Hyperlane подходящим решением для различных уровней требований к безопасности.

Одним из ключевых преимуществ Hyperlane является функциональность Warp Routes, которая обеспечивает мгновенные и без-слиппеджевые (no-slippage) транзакции для обмена токенами между чейнами. Warp Routes позволяет пользователям подключать любые токены с низкими комиссиями и высокой скоростью, что делает процесс удобным и доступным.

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

1. Deploy Hyperlane — настройка протокола Hyperlane на выбранной сети для отправки и получения сообщений внутри сети.

2. Create Warp Route — создание маршрутов для обмена токенами через командную строку.

3. Launch Warp UI — запуск пользовательского интерфейса, который позволяет пользователям взаимодействовать с созданными маршрутами, обеспечивая простоту использования и удобство для конечных пользователей.

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

Источник: обзор протокола в документации и главная страница.

В DefiLlama проекта нет, но нашёл несколько Dune дашбордов.

Первый - anonvee/hyperlane-leaderboard-rank:

Здесь можно посмотреть рейтинг кошельков по количеству транзакций (считаю бесполезными данными).

Вторая таблица позволяет посмотреть рейтинг по объёмам в tia.n на Trader Joe.

danrechi/hyperlane-stats:

Интересно, что

• общая сумма собранных комиссий по данным дашборда $3,070,996.

• Всего 252,939 транзакций с Superform, использующих Hyperlane

• Пользователей - 613,272

• Также можно посмотреть таблицу лидерборда по количеству транзакций

• Не пойму, что означает процесс транзакций, но значение тут 3,978,572

• Есть также анализ вовлечённости пользователей (график) на основе количества транзакций на пользователя

realpeha/hyperlane:

Здесь:

• График средних сборов Hyperlane

• Количество транзакций назначения в каждой сети (график)

• Также есть количество пользователей - 613,908

• И рейтинг по количеству транзакций

• График уникальных пользователей за день

• График новых пользователей

• Среднее число транзакций - 3

• Таблица поддерживаемых блокчейнов (показано 43). Здесь можно узнать название, domain id и есть ли полная поддержка

• Общая комиссия по блокчейнам (график)

• График количества исходных транзакций по блокчейнам

• Пишут, что всего собрано комиссий на $3,050,235

• количество транзакций на одного отправителя (таблица) по проектам на Hyperlane.

• среднее время доставки (график)

• совокупное количество транзакций (график)

• Средний показатель txsHyperlane: статистика - 7

• Количество транзакций по дням (график)

• Общее количество сообщений на Hyperlane: 5,325,081

• 4,324 отправителя (как понимаю речь про смарт-контракты)

• количество транзакций на маршрут (график)

• Дневные комиссии по блокчейнам (график)

Оценка 4 из 5: Идея интересная, аналитика пусть и не очень существенную активность показывает, но тем не менее уже и немалую... Но ещё неизвестно, как протокол себя покажет, сможет ли конкурировать с существующими, поэтому 4 из 5.

Токеномики нет, но есть инвестиции в проект по данным Cryptorank:

Вложили 18,5 МЛН $ Circle, Variant, CoinFund, Kraken Ventures, Figment Capital, NFX, Blockdaemon Ventures и Galaxy Ventures.

Оценка 3 из 5: инвестиции хорошие и от нескольких инвесторов, но токеномики и ютилити нет.

Есть Github репозитории:

Их 38, поэтому показывать буду некоторые (которые посчитаю основными).

hyperlane-xyz/hyperlane-registry:

Коллекция конфигураций, артефактов и схем для Hyperlane. Дополнительную информацию смотрите в документации.

Последний коммит (обновление) 5 часов назад:

Всего - 338 коммитов:

Хорошая активность в плане разработки... Добавляют и новые функции, и функции добавляют / изменяют.

hyperlane-xyz/hyperlane-monorepo:

База для контрактов Hyperlane core, пакетов sdk и другой инфраструктуры

Последний коммит 42 минуты назад:

Всего - 2,789 коммитов:

Тоже активная разработка...

hyperlane-xyz/hyperlane-explorer:

Веб-приложение для Hyperlane Explorer

Последний коммит был вчера:

Всего 433 коммита:

Менее активно развивают, тем не менее коммиты периодически выпускают.

hyperlane-xyz/hyperlane-warp-ui-template:

Шаблон веб-приложения для создания пользовательских интерфейсов Hyperlane Warp Route

Последний коммит был 3 дня назад:

Всего 234 коммита:

Периодически обновляют, что здорово.

Есть и аудиты кода:

Рассмотрим 3 из указанных аудита:

1. Hyperlane V3 (Trail of Bits): Аудит V3 показал высокий уровень безопасности, без критических уязвимостей. Все выявленные проблемы были устранены. Основные рекомендации касались улучшения качества кода и поддержки актуальности документации. Тесты и механизмы проверки были признаны адекватными, но для обеспечения безопасности предложено провести более углублённый аудит, так как найденные в ходе аудита мелкие уязвимости (например, потенциальная двойная трата) могут критически влиять на протокол. Потенциальная двойная трата, кстати, была исправлена до завершения аудита.Протокол получил умеренные оценки за управление сложностью и документацию, из-за высокой сложности нового кода и долгих цепочек вызовов .

2. Hyperlane V2 (Hacken): В ходе аудита V2 были выявлены две средние и две низкие уязвимости. Уровень безопасности проекта оценён на 8 из 10, а общая оценка составила 8.6. Основные проблемы касались обновляемости (необходимость устранения ошибок в конфигурациях для предотвращения потерь данных) и соблюдения лучших практик. Общая кодовая база оценена положительно, с полной тестовой покрытостью .По состоянию на второй аудит, проведённый в апреле 2023 года, все критические и высокие уязвимости были устранены. Из двух средних и двух низких уязвимостей большая часть также была исправлена, включая вопросы безопасности обновляемости.

3. Hyperlane cw (Oak Security): В ходе аудита функционала CosmWasm (cw) были найдены несколько уязвимостей средней и низкой тяжести. Проблемы касались устойчивости к атаке отказа в обслуживании (DoS), недостатка проверок входных данных и неэффективности некоторых операций. Аудиторы отметили высокую сложность и предложили улучшить структуру дерева Merkle, оптимизировать проверки и обработку данных. Состояние документации и тестов было признано средним, что может требовать доработок .Часть выявленных проблем также была решена. Например, решены проблемы с отсутствием валидации входных данных и неэффективностью Multisig ISM. Некоторые рекомендации, такие как оптимизация структуры дерева Merkle и улучшение обработки данных в Multisig ISM, были признаны проектом, но не исправлены полностью, поскольку клиент планировал управлять параметрами в операционной среде

Оценка 5 из 5: активная разработка, наличие нескольких аудитов разных частей кода, его открытость - в общем, отлично!

Сайт: https://docs.hyperlane.xyz/

Рассмотрим все разделы.

Введение в Hyperlane

Что такое Hyperlane?

Hyperlane — это кроссчейн-протокол для взаимодействия между сетями без разрешений. Он обеспечивает передачу сообщений и перемещение активов между разными сетями без необходимости в централизованных посредниках или дополнительных разрешениях.

Почему стоит выбрать Hyperlane?

Модель Hyperlane, не требующая разрешений, позволяет любому пользователю развернуть Hyperlane в любой блокчейн-среде, будь то первый уровень (layer 1), роллап или специализированная сетевая платформа (app-chain), и сразу приступить к созданию кроссчейн-приложений — без согласований и посредников. Это даёт разработчикам полный контроль над тем, как их децентрализованное приложение функционирует в мультичейн-среде, устраняя узкие места и улучшая масштабируемость.

Hyperlane был разработан с учетом модульности: его Интерчейн-модули безопасности (ISM) позволяют разработчикам настраивать, комбинировать и адаптировать модель безопасности в соответствии с потребностями их приложений.

Начните разрабатывать с Hyperlane

Некоторые предварительно разработанные примеры, которые можно развернуть сразу, включают:

1. Warp-маршруты — позволяют нативным токенам и токенам ERC20 перемещаться между сетями без препятствий.

2. Интерчейн-аккаунты — позволяют аккаунту в одной сети (например, DAO) выполнять ончейн-вызовы смарт-контрактов в удаленных сетях.

3. Интерчейн-запросы — позволяют аккаунту в одной сети выполнять оффчейн-запросы для получения данных в удаленных сетях.

Как соединить вашу сеть с Hyperlane:

Этот гайд поможет вам как можно быстрее развернуть Hyperlane в вашей новой сети для тестирования, а не для продакшена. В него входят основные контракты почтового ящика (mailbox) и ISM, а также контракты warp-маршрутов для активов, которые вы перемещаете.

Чтобы узнать, какие сети уже поддерживаются, посетите Registry. Если вам потребуется помощь, обращайтесь в канал #developers на Discord или свяжитесь напрямую.

Для интеграции понадобится ID блокчейна, его имя и RPC, а также приватный ключ кошелька-деплоера/EOA или seed-фраза (этот EOA должен быть профинансирован как в вашей кастомной сети, так и в любой сети, с которой будет осуществляться обмен сообщениями) и Hyperlane CLI.

Далее идёт инструкция с командами и конфигами, которая не всем будет понятна / интересна, поэтому её пропущу. При желании можете изучить, зайдя на страницу.

Интересно то, что после запуска просто делаете PR (пул-реквест), и сеть будет добавлена, если всё правильно в нём указано, и функционал Hyperlane с вашей стороны работает.

Если возникли неполадки при деплое сети, изучайте соответствующую страницу (я её описывать не буду).

О переходе к производству (продакшену) (целый раздел про это написан).

Перейдём к разделу для разработчиков смарт-контрактов. Я тут покажу тоже только одну страницу в качестве примера - Как создать мост для токена с помощью Hyperlane Warp Routes:

Создайте кроссчейн-мост для токена без необходимости разрешений, развернув контракты Hyperlane Warp Route.

Предварительные требования: Hyperlane CLI и Приватный ключ для подписания транзакций контрактов

Подробности опустим, т. к. они многим неинтересны.

После завершения деплоя переходите к развёртыванию интерфейса моста.

Интересно, что можно создать Warp-маршрут с доходностью благодаря интеграции с ERC-4626, которую распределять между основателем моста и пользователями.

Чтоб облегчить пользователям вашего L-2 (если он есть) взаимодействие без ожидания 7 дней вывода в L-1 для передачи в другой L-2, можно создать Warp-маршрут быстрых собственных переводов с помощью пользовательских Газовых токенов.

Если у вас уже есть Warp-маршрут, можете его расширить в новый блокчейн.

Кстати, Hyperlane поддерживает и SVM чейны, например, Solana. Вот инструкция по деплою WARP-маршрута SVM.

Также в разделе для разработчиков смарт-контрактов есть страница по созданию своего собственного хука & ISM для взаимодействия с другими протоколами или иного...

В советах для разработчиков дана информация по юнит-тестам, а также источникам и кранам токенов.

Далее - для агентов операторов.

Быстрый старт: запуск валидатора:

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

Для более подробной информации ознакомьтесь с гайдом по валидаторам.

Терминология

"Локальная сеть" — это ваша новая сеть, на которую вы хотите развернуть Hyperlane.

"Удаленная сеть" — это сеть с уже существующим развертыванием Hyperlane, с которой ваша локальная сеть будет отправлять и получать сообщения.

Запуск валидатора

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

Саму установку не буду описывать: долгая и сложная...

Также есть инструкция по запуску релеера (ретранслятора):

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

Для более подробной информации ознакомьтесь с гайдом по релеерам.

https://t.me/denis_skripnik

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

Mailbox:

Смарт-контракты Hyperlane Mailbox предоставляют on-chain API для отправки и получения кроссчейн-сообщений. Контракт Mailbox развернут в каждой сети, которую поддерживает Hyperlane.

Сеть Mailbox обеспечивает связь между блокчейнами, которую разработчики используют для создания кроссчейн-приложений и добавления кроссчейн-функционала в свои существующие приложения.

Для отправки сообщений надо вызывать функцию dispatch, а для получения - handle:

• dispatch(destination, recipient, body)

• handle(origin, sender, body)

Каждое сообщение обладает своим nonse, который уникален для каждого mailbox.

Структуру сообщения пропустим и некоторую другую информацию, т. к. она особо не важна, а перейдём к описанию процесса отправки сообщения.

Чтобы отправить кроссчейн-сообщения, разработчики вызывают Mailbox.dispatch().

Эта функция принимает в качестве параметров содержимое сообщения, ID целевой сети и адрес получателя. Каждое сообщение вставляется как лист в инкрементальное дерево Меркла, хранящееся Mailbox.

Протокол Hyperlane с доказательством доли использует это дерево Меркла для проверки доказательств мошенничества.

Process

Чтобы доставить кроссчейн-сообщения, релеер вызывает Mailbox.process().

Эта функция принимает в качестве параметров сообщение для доставки, а также произвольные метаданные, которые может указать релеер.

Mailbox передаст сообщение и метаданные модулю безопасности целевой сети для проверки. Если ISM успешно проверяет сообщение, Mailbox доставит сообщение получателю, вызвав recipient.handle().

Следующие страницы с подробностями по отправке и получению сообщений описывать не буду. Скажу лишь, что функция handle должна быть ограничена адресом Mailbox, если контракт должен принимать вызовы только от кроссчейн-сообщений, но это есть в библиотеке.

Кроссчейн платежи за Газ:

Успешные кроссчейн-сообщения требуют выполнения двух транзакций: одной в исходной сети для отправки сообщения и одной в целевой сети для доставки сообщения.

Для удобства Hyperlane предоставляет on-chain интерфейс в исходной сети, который позволяет отправителям сообщений оплачивать сборы релееру за доставку сообщения в целевую сеть. Эта оплата называется кроссчейн-газовой оплатой.

Кроссчейн-газовые платежи осуществляются с помощью смарт-контрактов InterchainGasPaymaster (IGP).

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

Каждый контракт InterchainGasPaymaster соответствует ровно одному релееру. Адреса релееров Abacus Works можно найти в разделе адресов.

Кроссчейн-газовый платеж рассчитывается следующим образом:

gasLimit и exchangeRate настраиваются отправителем сообщения и релеером соответственно.

Лимит газа устанавливается на основе стоимости вызова функции handle в целевой сети для данного сообщения. Это может варьироваться в зависимости от содержимого сообщения и логики обработчика. Отправитель сообщения должен настроить лимит газа на основе ожидаемых затрат на обработку сообщения, при этом используется значение по умолчанию, если лимит газа не настроен.

См. справку по хуку кроссчейн-газов для получения более подробной информации.

Post-Dispatch хуки:

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

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

Подробности опустим, т. к. они нужны лишь разработчикам.

Интерчейн-Газовые платежи:

Для доставки сообщения транзакция должна быть включена в целевую сеть, которая вызывает функцию process Mailbox с закодированным сообщением и метаданными ISM.

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

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

Подробности опустим.

OP Stack хук:

Оптимизм и другие OP Stack роллапы имеют свой собственный интерфейс для передачи сообщений между L1 и L2, называемый CrossDomainMessenger. Сообщения, передаваемые через этот интерфейс, получают выгоду от безопасности слоя расчетов роллапа.

Чтобы предоставить эту безопасность в качестве опции в Hyperlane, мы создали комбинацию хуков и ISM, которые могут быть прозрачно настроены для повторного использования нативного интерфейса OP Stack.

Смотрите страницу с адресами для адресов хуков и ISM.

Как это работает

OPStackHook отправляет messageId в L1CrossDomainMessenger, который регистрирует его как событие Optimism TransactionDeposited с депозитом ETH и данными сообщения, которые затем захватываются нодой роллапа. Нода роллапа вызывает предкомпилированный контракт L2CrossDomainMessenger с функцией relayMessage, которая, в свою очередь, делает вызовы к настроенному контракту OptimismISM, устанавливая messageId в отображении verifiedMessageId на оригинального отправителя L1 (то есть пользователя). Релеер передает только сообщение без метаданных, ожидая, когда нода Optimism выберет его и сделает запись в хранилище, после чего доставка сообщения подтверждается.

Хук Arbitrum L2 to L1:

Система Outbox в Arbitrum позволяет выполнять произвольные вызовы контрактов с уровня 2 (L2) на уровень 1 (L1) после оптимистичного периода оспаривания, т.е. сообщения, инициированные в сети L2, которые в конечном итоге выполняются на L1. Более подробную информацию можно найти здесь. Hyperlane может использовать систему Outbox для того, чтобы задействовать оптимистичную безопасность Arbitrum L2 (с 7-дневным периодом вывода и операционными доказательствами мошенничества) для защиты сообщений с L2 на L1 из любых роллапов Arbitrum Nitro. Был реализован ArbL2ToL1Hook и ArbL2ToL1Ism.

Как это работает

Примечание: Исходящие сообщения с L2 не могут обеспечить автоматическое выполнение на L1 в рамках протокола, поскольку Ethereum не предоставляет возможностей для запланированного выполнения через ноду L1.

ArbL2ToL1Hook отправляет закодированный вызов функции с идентификатором сообщения в предкомпилированный контракт ArbSys на L2. После ожидания периода вывода вы можете вызвать getOutboxProof() на L2 для получения доказательства меркле сообщения. С этого момента у вас есть два варианта:

• Вариант A. Вы можете вызвать функцию проверки ArbL2ToL1Ism через вызов mailbox.process() с доказательством и другими закодированными данными, что в свою очередь вызывает outbox.executeTransaction(), проверяя корректность отправителя сообщения и данных сообщения.

• Вариант B. Вы можете напрямую вызвать outbox.executeTransaction() с доказательством и другими закодированными данными. Однако вам потребуется сделать второй вызов функции проверки ArbL2ToL1Ism, чтобы доставить сообщение. Этот вариант также позволяет доставку значений сообщения в контракт получателя.

Подробности опустим. Главное суть передал.

Хук Polygon PoS:

Polygon PoS имеет свой собственный интерфейс для передачи сообщений между Ethereum и Polygon, называемый fx-порталом. Сообщения, передаваемые через этот интерфейс, получают выгоду от механизма синхронизации состояния Polygon.

Чтобы предоставить эту безопасность в Hyperlane, была создана комбинация Hook и ISM, которую можно прозрачным образом настроить для повторного использования интерфейса fx-портала.

Как это работает

Polygon FX-портал предоставляет контракты FxChild (FxChild.sol) и FxRoot (FxRoot.sol) в качестве основных контрактов, на которых работает мост. Он вызывает и передает данные на пользовательские методы в другой сети без необходимости создания маппингов.

Контракты FxChild и FxRoot предоставляются и поддерживаются командой Polygon. Вы можете найти адрес этих контрактов в репозитории fx-портала Polygon.

Контракт PolygonPosHook отправляет полезные нагрузки с использованием FxRoot. Валидационные ноды получат сообщение и передадут его в другую сеть. Подробную информацию о механизме синхронизации состояния можно найти в документации StateReceiver.

Адрес 0x0000000000000000000000000000000000001001 может вызывать функцию onStateReceive в контракте FxChild. Контракт FxChild вызывает processMessageFromRoot в абстрактном классе CrossChainEnabledPolygonChild, который реализует PolygonPosISM. CrossChainEnabledPolygonChild поддерживается OpenZeppelin.

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

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

Как это работает

1. Настройка (Configure)Hyperlane определяет набор заранее подготовленных ISM. Разработчики могут развертывать любые из этих контрактов "с полки" и настраивать их под свои параметры. Например, разработчики приложений, которые хотят повысить суверенитет над кроссчейн безопасностью, могут развернуть Multisig ISM, настроенный с валидаторами, выбранными из их собственного сообщества.

2. Композиция (Compose)ISM действуют как "безопасные лего". Разработчики могут комбинировать различные ISM, чтобы закодировать модель безопасности, которая наилучшим образом соответствует их потребностям. Например, разработчики приложений, которые хотят дополнительной безопасности, могут развернуть Aggregation ISM, требующий проверки как Multisig ISM, настроенного с валидаторами из сообщества Hyperlane, так и Wormhole ISM, который подтверждает, что кворум валидаторов Wormhole подтвердил сообщение.

3. Настройка (Customize)ISM полностью настраиваемы. Разработчики могут писать свои собственные ISM, адаптируя их под нужды своего приложения. Например, разработчики приложений могут создавать ISM, которые изменяют модели безопасности в зависимости от содержания сообщений. Сообщения высокой ценности и редкие (например, управление) могут проверяться моделью безопасности, которая ставит безопасность выше задержек и затрат на газ. Сообщения низкой ценности и более частые могут проверяться моделью безопасности, которая ставит приоритет на задержки и затраты на газ выше безопасности.

Получатели сообщений могут указывать свои собственные ограничения безопасности, указывая адрес модуля кроссчейн безопасности (InterchainSecurityModule). Эта реализация может быть настроена, скомпонована и адаптирована в соответствии с потребностями их приложения.

Диаграмма последовательности:

Следующая схема демонстрирует упрощенную последовательность проверки и доставки кроссчейн-сообщения на целевом чейне.

ИНФО

Если получатель не реализует ISpecifiesInterchainSecurityModule или recipient.interchainSecurityModule() возвращает address(0), будет использован ISM по умолчанию, настроенный на Mailbox, для проверки сообщения.

Это опущено в схеме последовательности для ясности.

Саму схему можете посмотреть на странице.

Переопределение ISM по умолчанию:

Разработчики могут указать или переопределить ISM по умолчанию, реализовав интерфейс ISpecifiesInterchainSecurityModule в своем приложении.

Конкретно этот интерфейс должен быть реализован в том же смарт-контракте, который реализует функцию handle().

Если ISM не указан или если указанный ISM является нулевым адресом, будет использован тот ISM, который настроен по умолчанию на Mailbox целевого чейна.

Подробности на странице.

Multisig ISM:

Проверка сообщений с использованием подписей валидаторов

Multisig ISM — это один из наиболее распространенных типов ISM. Эти ISM проверяют, что m из n валидаторов подтвердили действительность конкретного кроссчейн-сообщения.

Подробности о структуре на странице.

Routing ISM:

Разработчики могут использовать Routing ISM для делегирования проверки сообщений другому ISM. Это позволяет изменять модели безопасности в зависимости от содержимого сообщения или контекста приложения.

Этот ISM просто переключает модели безопасности в зависимости от чейна-источника сообщения. Простой пример использования заключается в применении различных наборов валидаторов для Multisig ISM для каждой сети.

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

Aggregation ISM:

Разработчики могут использовать AggregationISM для объединения безопасности от нескольких ISM. Проще говоря, AggregationISM требует, чтобы m из n ISM подтвердили подлинность конкретного кроссчейн-сообщения.

Разработчики могут настроить для каждой исходной сети набор из n ISM и количество ISM, необходимых для подтверждения сообщения. AggregationISM может агрегировать безопасность любых ISM. Например, пользователи могут развернуть Multisig ISM с собственным набором валидаторов и развернуть AggregationISM, который объединяет этот ISM с дефолтным ISM Hyperlane.

CCIP Read ISM:

Использование CcipReadIsm предоставляет разработчикам большую гибкость верификации кроссчейн сообщений. В конечном итоге каждый другой тип ISM может быть реализован как CCIP Read ISM, поэтому при создании новых типов ISM в будущем рекомендуется строить CCIP Read ISM, так как работа по интеграции с релейерами уже выполнена.

Однако стоит учитывать, что CCIP Read ISM вводит зависимость от внешнего (по отношению к блокчейну), но само размещаемого API. Если это является серьезным препятствием для вашего случая использования, возможно, стоит рассмотреть другие техники верификации сообщений.

Перед созданием CCIP Read ISM стоит ознакомиться со спецификацией CCIP Read. Спецификация описывает обобщенный протокол, который позволяет смарт-контрактам на совместимых с EVM чейнах запрашивать и использовать оффчейн данные.

Как это работает

Релейер будет постоянно слушать события Dispatch, генерируемые Hyperlane Mailbox. Когда сообщение отправляется и захватывается релейером, он запросит у назначения ISM информацию о том, как обработать сообщение и будет ли доставка успешной.

ИНФОРМАЦИЯ Переменная moduleType должна быть правильно установлена в вашем ISM, чтобы релейер знал, что это CCIP Read ISM. Чтобы убедиться, что это настроено правильно, вы можете унаследоваться от AbstractCcipReadIsm в @hyperlane-xyz/core.

Затем релейер вызовет функцию getOffchainVerifyInfo(bytes) на ISM с содержимым доставляемого сообщения. Эта функция должна отклоняться с ошибкой OffchainLookup, описанной в разделе интерфейса, описанного на странице.

Релейер запросит конечную точку, указанную в этом сообщении об отклонении, и передаст предоставленный ответ и оригинальное сообщение в функцию process(bytes, bytes) назначения Mailbox.

Переходим к общественным ISM.

• Wormhole ISM уже описывался кратко выше. Скажу лишь, что он ещё не реализован (по данным из документации), но будет работать следующим образом:Для принятия сообщения надо будет, чтоб 13 из 19 валидаторов Wormhole приняли его.

• Optimistic ISM также ещё разрабатывается. Позволит добавить безопасность за счёт проверки мошенничества с задержкой и без существенных затрат по Газу.

• Op Stack ISM используется, и уже описан в Op Stack хуке.

• Polygon PoS ISM используется вместе с хуком Polygon PoS для использования механизма синхронизации состояния Polygon с целью обеспечения безопасности сообщений, передаваемых между Ethereum и Polygon PoS chain. Подробности были описаны в Polygon PoS хуке.

• Arbitrum L2 to L1 ISM используется вместе с хуком Arbitrum L2 to L1 для использования безопасности Arbitrum rollup для сообщений, передаваемых с Arbitrum L2 на Ethereum. Подробности были описаны в соответствующем хуке.

Протокол Hyperlane отделяет транспортный уровень от уровня безопасности при кроссчейн-передаче сообщений. Для выполнения развертывания он полагается на оффчейн-агентов, которые отслеживают ончейн-активность и выполняют транспортные аспекты или аспекты безопасности протокола.

Эти агенты реализованы на языке Rust и распределяются в виде образов Docker и бинарных файлов.

1. Релейеры выполняют требования по транспортировке сообщений протокола. Они агрегируют оффчейн-метаданные безопасности для интерфейса IInterchainSecurityModule и доставляют сообщения их получателям.

2. Валидаоры обеспечивают безопасность протокола в рамках Multisig ISM или Hyperlane AVS, подтверждая действительность сообщений Mailbox и предоставляя свои подписи релейеру.

Релеер:

Релейер выполняет транспортный уровень протокола Hyperlane, доставляя сообщения от исходных до целевых чейнов. В зависимости от кроссчейн-секьюрити-модуля (ISM), указанного получателем, может потребоваться метаданные для подтверждения безопасности сообщения, такие как подписи валидаторов для Multisig ISM, меркле-доказательства, доказательства с нулевым разглашением и др. Поэтому перед попыткой доставки релейер собирает любые специфические для ISM метаданные.

Совет

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

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

Релейеры могут легко настраивать сообщения, которые они хотят обрабатывать. В настоящее время релейер поддерживает:

1. Черный и белый списки отправителей и получателей.

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

Хотя запуск релейера не требует разрешений, отправителю сообщения необходимо выбрать, какому релейеру платить за доставку. Интеграции Mailbox обычно по умолчанию оплачивают одного и того же релейера, но отправители сообщений могут отказаться от этого. Для удобства Hyperlane будет запускать открытый и настраиваемый агент релейера, реализованный как бинарный файл на Rust. Если вы хотите запустить свой собственный релейер, разработчики Hyperlane открыли исходный код бинарного файла здесь.

Запуск собственного релейера включает развертывание контракта IGP и поддержание курсов обмена токенов и цен на газ внутри него для точного расчета сборов за доставку сообщений.

Информация

Хотите запустить релейер? Следуйте гайду для релейеров.

Подробности не всем интересны, поэтому опустим (смотрите на странице).

Скажу лишь, что исторические и новые сообщения индексируются с помощью запросов событий контракта Mailbox через RPC. Оплаты газа также индексируются для подтверждения того, что отправители оплатили доставку, и определенные ISM используют дополнительные данные исходного чейна. Это касается Multisig ISM, который полагается на контракт Merkle Tree Hook, чтобы информировать релейера о том, какая подпись валидатора соответствует какому сообщению. Для каждого типа события (сообщения, IGP, вставка Merkle Tree) создается отдельная задача индексации.

Индексатор записывает данные в локальную базу данных (RocksDB) в качестве кэширования, а также для связи с задачей Submitter, которая периодически опрашивает базу данных для проверки наличия новых отправленных сообщений. Релейер отдает приоритет новым сообщениям перед старыми, предполагая, что старые сообщения с большей вероятностью уже были доставлены. Это означает, что при (пере)запуске создаются два указателя: один для прямого, другой для обратного движения, оба инициализируются на верхушке блокчейна и используют поле монотонно увеличивающегося nonce сообщений для итерации.

Похожий подход используется для индексации других событий, но некоторые из них не имеют номера последовательности и могут быть пропущены, если получены некорректные ответы RPC — что случается довольно часто. В связи с этим задача индексации сообщений отправляет идентификаторы транзакций, где были обнаружены события, другим задачам индексации, что гарантирует, что ни одно событие Hyperlane не будет пропущено, если оно произошло в рамках одной транзакции с вызовом Mailbox.dispatch().

Валидаторы:

Валидаторы работают в рамках Multisig ISM или Экономического Модуля Безопасности, выполняя функцию слоя безопасности протокола Hyperlane. Если используется другой ISM, валидаторы не требуются. Они несут ответственность за аттестацию сообщений, подписывая корень Меркла (также называемый контрольной точкой) при новых отправках в Mailbox. Подписи должны быть доступны для того, чтобы любой (обычно релейер) мог их получить и отправить вместе с сообщением на целевой чейн.

В отличие от многих других протоколов, Hyperlane не имеет установленного набора валидаторов. Каждый может запустить своего валидатора, если контракт-получатель указывает Multisig ISM, который включает их валидатор. Контрольные точки валидаторов являются общедоступными. Это гарантирует, что транспортный слой не требует разрешений, поскольку любой может получить подписи и вызвать Mailbox.process() для доставки сообщения. Релейер просто предоставляет удобный сервис для отправителей сообщений.

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

Hyperlane разрабатывает валидатор в виде бинарного файла, реализованного на Rust, который может легко запустить любой желающий. Оперативно валидаторы должны запускать этот бинарный файл и иметь доступ к RPC-поставщику или ноде для чейна, который они валидируют. Основатели надеются, что большинство валидаторов Hyperlane будут из существующего сообщества операторов нод каждого чейна.

Хотите запустить валидатор? Следуйте гайду для валидаторов.

Валидатор выполняет две основные задачи: индексатор для исходной цепочки и отправитель контрольной точки для публикации подписанных корней Меркла.

Подробности также опустим.

Хотя важно сказать, что если используется Hyperlane AVS, валидатор должен стать оператором AVS.

Варп-маршруты:

Разработчики могут использовать Hyperlane для безразрешительной развертки Warp Routes — контрактов, которые позволяют любым токенам ERC20, ERC721 или нативным токенам беспрепятственно перемещаться между чейнами.

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

Как и все приложения, построенные на Hyperlane, Warp Routes обладают настраиваемой безопасностью через Модули Кроссчейн Безопасности (Interchain Security Modules). Это позволяет развертывателям Warp Route настраивать и применять индивидуальные правила и ограничения, которым должен соответствовать кроссчейн токен.

Warp Routes могут быть развернуты между любым набором чейнов, на которых уже есть развертывания Hyperlane. Если вы хотите создать Warp Route, который включает чейн, на котором Hyperlane в настоящее время не развернут, не стесняйтесь задеплоить Hyperlane самостоятельно!

Архитектура Warp Route

Контракты Warp Route передают ценность между чейнами, блокируя токены залога на исходном чейне (так называемом залоговом чейне) и затем создавая обернутые токены на целевом чейне (синтетическом чейне). Диаграмма на странице предоставляет упрощённый план процесса создания вашего Warp Route и результирующего актива.

Каждый Warp Route состоит из одного контракта, развернутого на каждом чейне, между которым может перемещаться токен. Эти контракты используют Mailbox для отправки кроссчейн-сообщений друг другу.

Когда пользователь переводит токены с канонического исходного чейна на неконанический целевой чейн, их токены блокируются в контракте HypERC20Collateral, который отправляет сообщение на целевой чейн для создания обернутых токенов.

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

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

Warp Route Interface

:

Hyperlane Warp Routes используют интерфейс IHypERC20 токена. Токены Warp Route реализуют этот интерфейс, который расширяет стандартный интерфейс ERC20.

Solidity код смотрите на странице.

Деплоер Warp Route может по желанию указать модули кроссчейн безопасности (ISM), которые используются для проверки сообщений о кроссчейн-передачах. Это означает, что каждый Warp Route может иметь уникальную конфигурацию безопасности. Пользователи, переводящие кроссчейн токены, должны понимать предположения о доверии маршрута перед его использованием.

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

Чтоб развернуть Warp-маршрут, следууйте пошаговой инструкции.

Warp маршруты: типы:

Warp Routes представляют собой реализацию моста для токенов в Hyperlane, позволяя безразрешительное перемещение нативных, ERC20 и синтетических (новоразвернутых ERC20) активов между любыми чейнами через Hyperlane. В данном документе представлены детали всех типов маршрутов.

Обратите внимание, что этот документ не включает маршруты ERC721.

Я не буду подробно описывать их: просто перечислю:

1. Native Token Warp Routesобрабатывают передачу нативных газовых токенов (например, ETH на Ethereum или Arbitrum, MNT на Mantle) между различными чейнами. Прямой перевод нативных токенов без упаковки.

2. Collateral-Backed ERC20 Warp Routes позволяют передавать ERC20 токены между чейнами, блокируя их в качестве залога. Упаковывает существующие ERC20 токены в качестве залога для переводов, блокирует токены в контракте на исходном чейне, освобождает эквивалентные токены на целевом чейне, использует SafeERC20 для безопасных переводов токенов.

3. Synthetic ERC20 Warp Routes. создают новые токены на целевых чейнах, представляющие токены с исходного чейна.. Поддерживает постоянное общее предложение на всех чейнах, поддерживает пользовательские атрибуты токена (название, символ, десятичные знаки), выпускает новые токены на целевом чейне, сжигает токены на исходном чейне при возврате.

4. Все маршруты расширяют контракт TokenRouter, который предоставляет основную функциональность для переводов токенов.

5. FastTokenRouter расширяет TokenRouter и обеспечивает более быстрые переводы токенов через механизм ликвидности.

6. Специализированные расширения Warp Route: Быстрые переводы с коллатералом (FastHypERC20Collateral), Интеграция Vault (HypERC4626OwnerCollateral, HypERC4626Collateral), Токены, обеспеченные фиатом (HypFiatToken), Масштабируемые нативные токены (HypNativeScaled), Интеграция xERC20 (HypXERC20 & HypXERC20Lockbox).

Пример настройки и случай использования смотрите на соответствующей странице (я их описывать не буду).

Interchain Account Interface:

Разработчики могут использовать интерфейс Interchain Account для создания и управления аккаунтом на удаленном чейне из своего локального чейна. В отличие от общего обмена сообщениями, который требует от получателей реализации специфического интерфейса, Interchain Accounts (ICAs) позволяют разработчикам взаимодействовать с любым удаленным контрактом.

ICAs позволяют вам осуществлять удаленные вызовы из Чейна A в Чейн B с использованием роутера (InterchainAccountRouter). Вот как это работает:

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

• Вы можете закодировать свой вызов, который включает адрес назначения, данные вызова и msg.value для каждого вызова, сгруппированные в массив.

• Вы отправляете закодированный вызов на роутер Чейна A, который пересылается на роутер Чейна B.

• После декодирования вызовов роутер Чейна B проверяет, был ли вычисленный адрес уже развернут. Если нет, Hyperlane разворачивает контракт OwnableMulticall.

• Затем роутер выполняет многократный вызов на адрес ICA, который в свою очередь выполняет желаемый произвольный вызов на Чейне B.

Интерфейс Interchain Account присваивает каждому кортежу (uint32 origin, address owner, address remoteRouter, address remoteISM) уникальный адрес ICA. Отправитель является владельцем этого ICA на целевом чейне и может направлять его для выполнения произвольных функций через конечную точку InterchainAccountRouter.callRemote().

Для основных чейнов, поддерживаемых Hyperlane, вы можете использовать значения по умолчанию, установленные владельцем контракта роутера. См. раздел #overrides для получения информации о том, как выполнять вызовы на любой чейн.

Остальные подробности смотрите на странице.

Hyperlane CLI:

Hyperlane CLI — это официальный инструмент командной строки для развертывания контрактов Hyperlane на новых чейнах. Он также включает утилиты для взаимодействия с развернутыми контрактами и реестрами.

Установка

Совет: требуется Node версии 18 или новее.

Для глобальной установки CLI используйте команду npm install -g. Это сделает команду hyperlane доступной в любом месте вашего терминала.

# Установить с помощью NPM

npm install -g @hyperlane-xyz/cli

# Или удалить старые версии

npm uninstall -g @hyperlane-xyz/cli

Альтернативно, для выполнения отдельных команд вы можете использовать npx или dlx:

# Запуск через команду npx от NPM

npx @hyperlane-xyz/cli

# Или через команду dlx от Yarn

yarn dlx @hyperlane-xyz/cli

Использование

Чтобы просмотреть список доступных команд и их аргументов, выполните команду:

hyperlane --help

Некоторые общие параметры команд включают:

• --version: Отображает текущую установленную версию CLI.

• --registry: Устанавливает URI реестра для использования метаданных сети и адресов контрактов.

• --overrides: Устанавливает дополнительный путь для переопределений канонических данных реестра.

• log: Устанавливает формат логирования для CLI (по умолчанию "pretty").

• verbosity: Устанавливает уровень логирования для CLI (по умолчанию "info").

• key: Устанавливает ключ, который будет использоваться для подписания транзакций (по умолчанию переменная окружения HYP_KEY).

Реестры

По умолчанию CLI будет извлекать метаданные чейна и адреса контрактов из канонического реестра Hyperlane, но будет записывать новые конфигурации и развертывания в вашу локальную файловую систему. Для получения дополнительной информации см. страницу Реестры.

Есть также библиотеки. Я их подробно описывать не буду, т. к. они нужны лишь разработчикам. Просто перечислю:

• Mailbox Client предоставляет функции, которые позволяют подклассам легко отправлять сообщения через Mailbox переменную mailbox хранилища и разрешать доставку сообщений через onlyMailbox модификатор.

• Router. В этом шаблоне экземпляр контрактов приложения развертывается в каждой поддерживаемой приложением сети. Каждый экземпляр знает адреса экземпляров в других чейнах. Эти экземпляры используют Hyperlane для передачи информации и состояния между собой в удалённых сетях.

• TypeCasts

• Message

• Standard Hook Metadata

Как пользоваться Hyperlane Explorer:

Hyperlane Explorer может использоваться для поиска сообщений в любой сети с развертыванием Hyperlane. Можно подробнее ознакомиться с сообщениями, чтобы узнать больше о их свойствах и статусе. Сообщения к/от основных сетей можно искать по хешу транзакции, идентификатору сообщения или адресу отправителя/получателя. Для других сетей эксплорер можно настроить для поиска сообщений, предоставив конфигурацию сети.

Hyperlane Explorer поддерживает поиск сообщений с использованием следующих значений:

• Хеш транзакции, инициировавшей сообщение (origin tx)

• Хеш транзакции, доставившей сообщение (destination tx)

• Адрес аккаунта, который отправил исходную транзакцию

• Адрес аккаунта, который отправил целевую транзакцию

• Адрес отправителя сообщения

• Адрес получателя сообщения

• Идентификатор сообщения

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

Важно: По умолчанию эксплорер будет находить сообщения только в основных сетях Hyperlane. Чтобы просмотреть сообщения, отправленные на другие сети или полученные от них, ознакомьтесь с настройками PI Chains.

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

Настройка разрешённых чейнов:

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

Шаги для настройки:

1. Перейдите на главную страницу эксплорера и нажмите кнопку "Origin" (Исходная сеть) или "Destination" (Целевая сеть). Это откроет модальное окно выбора чейна.

2. В этом окне нажмите на иконку плюса в правом верхнем углу.

3. Отобразится форма, принимающая JSON или YAML, соответствующий схеме ChainMetadata.

Если предоставлена корректная конфигурация блок-эксплорера на основе Etherscan, Hyperlane Explorer будет использовать её для поиска необходимых сообщений. Если конфигурация не указана, будет использован RPC URL. Обратите внимание, что исследователи с API-ключами (даже бесплатными) работают быстрее и надежнее.

Примеры метаданных смотрите на странице.

Для получения примеров структуры метаданных чейна, можете ознакомиться с документами, предоставляющими примеры конфигураций, соответствующих схеме ChainMetadata. Это поможет правильно настроить необходимые параметры для работы с PI-чейнами.

GraphQL API:

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

Подключение к API

Для выполнения запросов к данным вы можете использовать любой предпочитаемый клиент или библиотеку GraphQL, подключившись к следующему URL:

https://api.hyperlane.xyz/v1/graphql

Используя GraphQL, вы сможете выполнять различные запросы для получения информации о сообщениях, состояниях транзакций и другой активности в системе Hyperlane. Примеры есть на странице.

Экономическая безопасность:

Информация:

Hyperlane стремится сделать мошенничество затратным. Стейкинг и слэшинг скоро будут реализованы, но на данный момент они еще не внедрены. Эта страница представлена только для информационных целей. Подробности могут измениться по мере совершенствования дизайна.

Стейкинг и слэшинг

Стейкинг и слэшинг позволяют добавить экономическую безопасность к Межцепочным модулям безопасности (ISM), которые зависят от подписей валидаторов, включая Multisig ISM и Optimistic ISM. Валидаторы Hyperlane могут по желанию участвовать в протоколе стейкинга Hyperlane. В дальнейшем, если эти валидаторы попытаются фальсифицировать или цензурировать межцепочные сообщения, их стейк и любой делегированный им стейк могут быть подвергнуты слэшингу.

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

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

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

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

Hyperlane AVS

:

Этот гайд поможет вам понять модуль AVS (Actively Validated Service) от Hyperlane, построенный на основе EigenLayer, протокола рестейкинга Ethereum.

На данный момент Hyperlane использует модель Proof of Authority для обеспечения безопасности, в которой доверенная группа валидаторов отвечает за поддержание безопасности. Однако, если какой-либо валидатор подписывает ошибочно или с злым умыслом, это не влечет за собой никаких последствий, так как у этих валидаторов нет экономической ставки. Это пробел, который модуль AVS предназначен для устранения.

AVS позволяет обеспечивать экономическую безопасность внутри протокола Hyperlane с минимальными затратами на создание новой сети валидаторов для каждого поддерживаемого чейна. Это достигается за счет использования общего пула стейкинга, который может обеспечить безопасность исходящих сообщений из и между роллапами. Основные участники этого процесса:

• Операторы - операторы EigenLayer, которые участвуют в AVS-сервисе Hyperlane и начинают валидировать исходящие сообщения из указанных сетей.

• Стейкеры - стейкеры EigenLayer, которые делегируют свой стейк операторам для обеспечения сети.

• Приложения - приложения, использующие Hyperlane, стремящиеся экономически обеспечить свои сообщения между чейнами.

Внимание: На данный момент слэшинг и выплаты вознаграждений для EigenLayer еще не активированы. В дополнение к AVS необходимо настроить подписи и валидацию в кроссчейн модуле безопасности (ISM).

Архитектура AVS

Ниже представлена диаграмма классов, описывающая архитектуру текущих контрактов модуля AVS. Ключевым моментом является поддержка паттерна "metaAVS" с интерфейсом IRemoteChallenger.

Остальное смотрите на странице.

Реализации альтернативных виртуальных машин

:

В то время как публичная документация Hyperlane в настоящее время сосредоточена на совместимости с EVM, основатели предлагают различные уровни поддержки для дополнительных экосистем. На данный момент эти экосистемы могут не иметь полной паритетности функционала или полной интеграции инструментов (например, поддержки TypeScript CLI). В настоящее время активно работают над расширением документации и инструментов для этих платформ. Если вам интересно создавать на основе этих технологий или приносить Hyperlane в другие новые экосистемы, можете связаться с основателями проекта в Discord.

• Реализация CosmWasm Hyperlane, реализованная и поддерживаемая командой Mitosis. Следуйте этому гайду по развертыванию на Cosmos appchain. Проект уже в сети Celestia, Stride и Neutron с июля 2024 года.

• Sealevel - это реализация Hyperlane v3 для Solana Virtual Machine, которая теперь работает на Solana и Eclipse, с дополнительными роллапами Solana, coming soon. Вы можете найти реализацию контракта Sealevel здесь.

• Протокол Hyperlane был реализован на Cairo для Starkware командой Pragma. Вы можете найти реализацию, находящуюся в разработке, здесь.

• Hyperlane был реализован в MoveVM командой Movement Labs. Вы можете найти реализацию, находящуюся в разработке, здесь. Эти контракты Move уже работают на тестовой сети Movement's M1.

• Найдите реализацию Sway от команды Hyperlane, находящуюся в разработке, здесь.

Если вас интересует больше информации о конкретной экосистеме или интеграции с ней, не стесняйтесь задавать вопросы в Discord.

Развернутые адреса

:

Можете их посмотреть на странице.

Идентификаторы домена

:

в этот список включены только развертывания в блокчейнах, которыми управляет Abacus Works (юридическое лицо основателей). Каждый может без разрешения развернуть Hyperlane в любом чейне — основатели создают реестр, чтобы отразить разрешенные развертывания сообщества.

Hyperlane использует уникальные идентификаторы для каждой поддерживаемой сети. Когда это возможно, идентификаторы доменов Hyperlane соответствуют идентификаторам блокчейнов EVM, но это не гарантировано, так как поддерживаются также не-EVM чейны.

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

Таблицу смотрите на странице.

Задержки:

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

Обратитесь к разделам на странице для конфигурации финальности блоков, используемой валидаторами Hyperlane.

Hyperlane Registries

:

Hyperlane может быть развернут в любой сети любым участником. Для того чтобы такие развертывания приносили пользу, их параметры должны быть известны. Реестры содержат метаданные сети, адреса контрактов и другую полезную информацию для взаимодействия с контрактами и инструментами Hyperlane. Канонический реестр поддерживается основной командой Hyperlane, и такие инструменты, как CLI и Explorer, могут использовать его данные.

Метаданные и артефакты для развертываний, выполненных основной командой Hyperlane, доступны здесь: https://github.com/hyperlane-xyz/hyperlane-registry.

Участники сообщества также могут добавлять свои развертывания в этот канонический реестр. Процесс добавления включает следующие шаги:

1. Сделать форк и клонировать репозиторий реестра.

2. Использовать CLI, указав флаг --registry с локальным путем к клонированному репозиторию.

3. Выполнить необходимые команды.

4. Запушить изменения в свой форк и создать pull-запрос.

Любой репозиторий на Github или локальный путь могут использоваться как пользовательский реестр, если они соответствуют структуре и схемам файлов канонического реестра. CLI поддерживает два аргумента командной строки для настройки используемого реестра:

• Флаг --registry устанавливает основной реестр (по умолчанию используется Github).

• Флаг --overrides задает дополнительный путь, позволяющий принудительно переопределить данные по умолчанию, например, для использования другого RPC URL в метаданных сети.

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

Как использовать, смотрите на странице (пример на node.js).

Также описаны инструкции по деплою:

1. Развертывание Hyperlane с помощью локальных агентов. Это руководство предназначено для продвинутых пользователей, которые в конечном итоге могут захотеть запустить агенты Hyperlane в среде, похожей на производственную. Оно будет охватывать основы того, как вручную настраивать и запускать агенты, но это не руководство по настройке продакшена.

2. Руководство по реализации Hyperlane для новой архитектуры сети: создание контрактов, агентов и приложений. Примеры на Solidity показаны.

Перейдём к ресурсам:

1. Описана отладка сообщений: ответы на вопросы о возникающих ситуациях.

2. Словарь терминов. Поскольку термины пояснялись в процессе документации, не вижу смысла описывать эту страницу.

3. FAQ. Ничего интересного, что бы не рассмотрели мы, нет.

4. И аудиты (ссылку на них давал в коде).

Обзор:

Hyperlane отделяет транспортный слой кроссчейн передачи сообщений от уровня безопасности. Для запуска развертывания протокол полагается на оффчейн-агентов, которые наблюдают за ончейн-активностью и выполняют либо транспортные, либо защитные функции.

1. Валидаторы Hyperlane — лёгкие оффчейн-агенты, ответственные за безопасность. Они отслеживают сообщения в Mailbox в исходной сети и, если нужно, подписывают корневое значение дерева Меркла, подтверждающее текущее состояние Mailbox.

2. Релееры выполняют транспортную функцию протокола, собирают метаданные безопасности оффчейн для интерфейса IInterchainSecurityModule и доставляют сообщения получателям.

Валидаторы обеспечивают безопасность протокола как часть Multisig ISM или Hyperlane AVS, подтверждая подлинность сообщений Mailbox и предоставляя свои подписи для релеера. Эти подписи хранятся и размещаются в общедоступных хранилищах (например, в S3), чтобы релееры и Interchain Security Modules могли их использовать. Валидаторы работают независимо, не требуют консенсуса друг с другом и не отправляют регулярные транзакции в сеть.

Для операторов, стремящихся поддерживать безопасность исходной сети, работа валидатором является важной функцией, содействующей децентрализации передачи сообщений в Hyperlane. Однако просто работа в качестве валидатора не гарантирует активное участие в защите сообщений: для этого Multisig ISM на целевой сети должен использовать ключ проверки подписи валидатора.

Валидаторы реализованы на языке Rust и распространяются в виде Docker-образов и исполняемых файлов.

👉 Подробнее о Валидаторах.

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

Релееры Hyperlane могут ретранслировать сообщения между несколькими исходными и целевыми сетями. Каждое сообщение требует выполнения двух транзакций:

1. Отправка сообщения в исходной сети.

2. Доставка сообщения в целевой сети.

Для выполнения своей задачи релеер:

• Отслеживает новые сообщения в исходной сети.

• Проверяет Interchain Security Module (ISM), указанный получателем, для получения необходимых метаданных безопасности (например, может извлекать подписи Multisig ISM из хранилища контрольных точек валидатора).

• После сбора метаданных релеер отправляет сообщение получателю на целевой сети.

Если доставка сообщения не удалась (например, из-за отсутствия ликвидности для выхода из контракта Warp Route), релеер повторяет попытку с экспоненциальным увеличением интервала до успешной доставки.

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

👉 Подробнее о Релеерах.

Для запуска валидатора Hyperlane требуется соблюдение нескольких технических условий:

1. Защищённый ключ подписиВалидаторы используют этот ключ для подписания последнего корня дерева Меркла Mailbox. Защита этого ключа крайне важна: его компрометация может позволить злоумышленникам подделывать сообщения, что приведёт к наказанию валидатора.В настоящее время агент валидатора Hyperlane поддерживает подпись с использованием ключей AWS KMS, доступных через API-ключи/секреты, а также ключей в шестнадцатеричном виде. Дополнительная информация доступна в разделе об агентских ключах (я его не стал описывать в связи со специфичностью).

2. Открытое хранилище для чтенияВалидаторы записывают свои подписи оффчейн в общедоступные и надёжные хранилища, чтобы релееры могли их собирать.Агент валидатора Hyperlane поддерживает хранение подписей в AWS S3, используя указанные выше API-ключи AWS, а также на локальной файловой системе для тестирования.Я считаю, что плохо это: лучше бы реализовали P2P сеть для передачи данных.

3. Проект с открытым исходным кодом допускает адаптацию для других решений хранения и ключей. В сообществе имеется незавершённый PR для поддержки GCS.

4. Сервер для запускаВалидаторы могут скомпилировать бинарный файл на Rust самостоятельно или использовать Docker-образ, предоставленный Abacus Works. Бинарный файл может быть запущен на любом облачном сервисе. Поддерживается развертывание нескольких экземпляров в разных регионах для высокой доступности, поскольку в Hyperlane нет понятия «двойной подписи».Минимальные требования к оборудованию и стоимости: валидаторы обычно запускаются на системе с 2-ядерным процессором, 2 ГБ оперативной памяти и 4 ГБ памяти, с ориентировочной стоимостью около $75 в месяц.

5. RPC-нодаВалидаторы выполняют простые вызовы для чтения корней дерева Меркла из Mailbox-контракта в сети, которую они проверяют. Необходимо использовать собственные URL-адреса RPC, а не общедоступные.

Внимание: для работы валидатором в сети Polygon mainnet требуется доступ к архивной ноде. Это связано с тем, что валидаторы должны подписывать корни только после достижения финальности, а для достижения финальности в Polygon требуется 256 подтверждённых блоков.

Сам гайд смотрите на странице.

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

Мониторинг и оповещение:

Информация о том, как получать уведомления и какие они бывают.

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

Требования

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

2. Ключи для подписания транзакцийРелейер должен быть настроен с использованием ключей для подписания транзакций на каждом целевом чейне (в этих сетях должны быть средства).Эти ключи используются для подписания транзакций, вызывающих метод Mailbox.process(). Релейер Hyperlane поддерживает использование ключей AWS KMS, доступ к которым предоставляется через API-ключи/секреты, или же простых шестнадцатеричных приватных ключей.

3. Сервер для запускаОператоры релейера могут либо скомпилировать бинарный файл на Rust самостоятельно, либо использовать Docker-образ, предоставленный Abacus Works.Бинарный файл можно запустить на облачных сервисах или других предпочитаемых платформах.

Остальную информацию смотрите на странице.

Фильтрация сообщений

:

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

Как это сделать, смотрите на странице.

Мониторинг и оповещение

:

Также можно настроить и получать уведомления. Информация о том, как это сделать, а также какие уведомления выдаются, смотрите на странице.

Конфигурация агента:

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

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

Подробности на странице.

А на странице Configuration reference можете посмотреть примеры файлов настройки.

В гайдах можно найти быстрый запуск с Докером, деплой с Terraform и гайд по оператору AVS.

Оценка 5 из 5: всё подробно и понятно. Жаль, что пока у проекта PoA используется, а это требует доверия к валидаторам сейчас. Но надеюсь, что запустят систему слешинга как можно скорее. Но поскольку к документации проблема эта не относится, минус балл не делаю.

На странице экосистемы вы не найдёте ссылок на приложения:

https://live.staticflickr.com/65535/54108023332_a98357813e_o.png

Но можете посмотреть блокчейны и их названия.

• Everclear - это бывший Connext, занимающийся чейн-абстракции, поэтому его в практике не будет.

• khalani - приложения нет

• Остальные рассмотрим.

А также:

1. Superform vault, в который стоит закинуть из Arbitrum. Возможно и другие хранилища поддерживают Hyperlane, но я не помню.Для подробного изучения советую прочитать обзор Superform.В практике подробно его рассматривать не буду.

2. Остальные рассмотрим (сами увидете, какие)...

"Connect Wallet":

Выбираем, подключаемся:

"Accept and Sign" и подписываем сообщение - всё:

Нажав на weETH, можно сменить токен (я сделал это на uniBTC, но потом вернул, т. к. его нет в Arbitrum):

Нажимаем по Ethereum:

И выбираем Arbitrum, например, и заполняем сумму:

"Deposit", одобряем расходование и подтверждаем транзакцию - всё:

Не вижу в инфе о транзакции использование Hyperlane... Возможно в будущем использовать будет, а возможно уже сейчас, но в фоне...

"Redeem" позволит вывести ликвидность:

Выбираем сеть отправки, нажав по "Cosmos Hub":

Выбираю тот же Arbitrum. Далее "Select Chain" и ввожу в поиске "Forma":

Выбирал её:

Токен получения выбран автоматически. Нажимаем "Connect Wallet":

Выбираем Cosmos кошелёк. Я выбрал Metamask - попросил поставить Snap и всякое такое... Результат:

"Connect EVM Wallet", выбираем и подключаем:

Нажимаю по ETH - появился список токенов.

Ввёл сумму - оказалось, что роут недоступен:

Выбрал TIA.n, обменяв на него предварительно, а вкачестве сети получения Cosmos Hub - получилось:

Правда в начале писал, что нужен NTRN: пришлось пополнять ATOM и менять на NTRN. В общем, для новых пользователей Cosmos экосистемы сайт бесполезен...

Нажимаю "Review swap":

"Confirm Swap" и отправляем транзакцию. Ждём 20 минут и идём в кошелёк:

Всё.

"Connect Wallet":

Выбираем тип кошелька (я - "Connect to Ethereum"):

Выбираю, подключаюсь и закрываю окно выбора кошельков. Результат:

Нажимаю по "On Ethereum" и выбираю сеть:

Выбрал Arbitrum.

"Select asset" и ввёл в поиске TIA:

Выбираю сеть:

Forma нет - выбрал Neutron. Ну и в сети отправки выбрал TIA.n, предварительно обменяв на него в swap.defillama.com. Сумму тоже указал:

"Swap". Тут "Set destination address":

Выбираю последний пункт:

"Confirm":

"Set recovery address", и также "Enter address manually", но ничего не меняется - адрес не принимает после нажатия по "Confirm".Оставлю: может у вас что обменять и получится...

"Connect wallet":

Выбираем тип сети (я Ethereum), сам кошелёк (подключил Metamask):

Заметьте: уже выбрана сеть отправки и получения, как в swapFast. Видимо как-то передают последний выбор... Хотя возможно это по умолчанию так...

Нажав по "neutron", можно выбрать другую сеть:

Выбрал Arbitrum.

Нажав в "To" по "arbitrum", меняю сеть:

"Select Token":

Выбираю "TIA.n". Ввожу сумму и адрес получателя:

"Continue":

"Send to Neutron" и подтверждаю в кошельке. Всё - ждём:

Можем скопировать id сообщения и вставить в explorer.hyperlane.xyz

Доставлено пишет. Нажмём по сообщению

Как видите, всё хорошо.

Подключение схоже:

Бридж тоже аналогичен предыдущему сервису:

Просто с конкретными сетями:

Я показывать уже это не буду.

Cryptorank bridge

Интерфейс stride стандартный для LST протоколов - показывать не буду. Да и статья о другом...

Нажимаем на странице моста "Connect Wallet":

Выбираете тип сети (я Ethereum):

Выбираем, подключаемся:

Можете добавить второй из Cosmos экосистемы, чтоб передавать туда активы:

Но Metamask здесь нет, чтоб использовать Snap от Leap wallet, поэтому пропущу...

Нажимаю по "Stride":

Поддерживаются только Celestia, Stride, Forma и Ethereum (он выбран в сети получения).

Кликнув по stTIA, можем выбрать токен, но он один доступен: показывать не буду.

Выбрал из Forma в Celestia:

Маршрут не поддерживается.

DsПодключил Leap (пришлось поставить расширение) и выбрал путь из Celestia в Forma, ввёл сумму и вставил адрес получателя:

"Bridge":

"Send to Forma" и подтверждаем в кошельке.

Нажав по транзакции можем увидеть, что всё успешно:

Всё.

"Connect wallet":

Выбираем, подключаем - результат:

Нажимаем по BSC и выбираем сеть:

Выбрал Base. Ввёл иную сумму:

"CLAIM":

Смотрим на комиссию и, если всё устраивает, нажимаем "Claim" и подтверждаем в кошельке.

После получения вставляем максимальный баланс. Я ещё изменил сеть получения:

"BRIDGE":

"Bridge" и подтверждаем в кошельке, если всё устраивает.

P. S. Не рекомендую злоупотреблять этим: поскольку число токенов неограниченное, это смахивает на сибильство (т. е. на накрутку ради аэрдропа).

"FREE MINT":

"MINT" и подтверждаем в кошельке, если всё устраивает.

Стала доступна вторая кнопка:

"BRIDGE":

"BRIDGE" и подтверждаем в кошельке.

Всё - ждём:

Не покажет обновлённый статус. Идём по ссылке "View in Hyperlane Explorer":

Готово.

Стандартный мост.

Жму по Arbitrum One:

Можно выбрать другую сеть, например, Op mainnet. Также выбрал и сеть получения другую (Scroll):

Ввёл сумму (комиссии большие), а также поменял местави сети через кнопку "Swap":

"Bridge" и подтверждаю в кошельке. Всё:

Можем убедиться, нажав по ссылке "Hyperlane Explorer":

Кликаем по времени сообщения:

Успешно.

Подобным Cryptorank app в плане этого функционала является merkly, поэтому его показывать не буду.

Приложение позволяет сминтить свой NFT и отправить через Hyperlane. Фишка в том, что вы создаёте свой уникальный NFT!

Нажимаем по кнопке сверху для раскрытия меню:

"Connect wallet":

Выбираем кошелёк и подключаемся.

Для создания NFT напишу название и описание.

"Auto-generate NFT Image" и жду. Нажав "Auto-generate" у названия и описания, можете сгенерировать их, но я оставлю свои.

"Get Mint" и подтверждаю в кошельке. Всё:

Можем отправить и твитнуть об NFT. Я нажимаю "Send" - появится кошелёк. Подтверждаем транзакцию - успешно:

По умолчанию отправляет в "Ancient8", в которой, кстати, нет токенов у меня.

Но можно выбрать другую сеть кликом по "Ancient8":

Кстати, нажав по кнопке меню, можем увидеть сеть:

А нажав по ней, выбрать другую:

Там же перейдём к "Bridge NFT":

И видим сминченное:

Можем перейти на его страницу:

Нажмём по "Arbitrum One$1.26":

И выберем другую. Я указал Gnosis:

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

Лидерборд:

Можете отслеживать себя тут, если интересно.

Плюс по сравнению с Cryptorank app в том, что создают похоже свой продукт.

Оценка 3 из 5: не везде поддерживаются все кошельки, роуты не зная заранее сложно подобрать, комиссии большие…

24 из 30 или 4 из 5.

• Команда: LinkedIn конечно на сайте нет, да и ссылки не у всех есть, но через поиск можно найти сотрудников, и у них хороший опыт работы с навыками, поэтому лишь минус один балл.

• Концепт: идея интересная, аналитика пусть и не очень существенную активность показывает, но тем не менее уже и немалую... Но ещё неизвестно, как протокол себя покажет, сможет ли конкурировать с существующими, поэтому 4 из 5.

• Коин: инвестиции хорошие и от нескольких инвесторов, но токеномики и ютилити нет.

• Код: активная разработка, наличие нескольких аудитов разных частей кода, его открытость - отлично, в общем!

• Документация: всё подробно и понятно. Жаль, что пока у проекта PoA используется, а это требует доверия к валидаторам сейчас. Но надеюсь, что запустят систему слешинга как можно скорее. Но поскольку проблема не относится к документации, минус балл не делаю.

• Практика: не везде поддерживаются все кошельки, роуты не зная заранее сложно подобрать, комиссии большие...

Благодарю за внимание. Писал статью 3 дня: буду рад распространению обзора и донатам.

С вами был незрячий программист, автор https://t.me/blind_dev - подписывайтесь на канал, чтоб получать новые обзоры, дайджесты статей из web3 сферы и новости по моим разработкам.

Проект, который в начале соединял Cosmos экосистему и EVM через Celestia и Forma chain, а потом расширил и до других сетей.

Фишкой является возможность самостоятельного добавления сетей через развёртывание смарт-контрактов Hyperlane и запуск ретрансляторов

Ссылку на LinkedIn нашёл через поиск, а не на их сайте или в документации...Да и компания называется иначе...

LinkedIn Abacus Works:

543 отслеживающих, последняя публикация 2 месяца назад получила 10 реакций и 2 репоста.Предыдущая была опубликована тоже 2 месяца назад. Получила 10 реакций и 2 репоста.

Прикольно, что у них в профиле есть вокансии: желающие могут их посмотреть.

Интересно, что в октябре 2022 у них было 8 сотрудников, а в октябре 2024 - 20.

Люди компании:

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

Gillian Nguyen:

9566 отслеживающих. Последняя публикация 6 дней назад. Она получила 12 реакций.Предыдущая была опубликована неделю назад, и получила 9 реакций.

Опыт работы:

• Lead Technical Recruiter в Abacus Works с февраля 2024

• Senior Technical Recruiter в Branch с января по декабрь 2023 (удалённая работа)

• В Meta: Engineering Leadership Talent - Production Engineering с апреля 2020 по апрель 2022, Engineering Leadership Talent - SWE (Software Engineering) с марта 2022 по начало 2023

• Technical Recruiter в dYdX с декабря 2018 по апрель 2020

• Talent Manager в Blockchain Works с января по октябрь 2018

Образование:

• University of Toronto: Bachelor's degree, Economics

• George Brown College: Design and Applied Arts

Навыки:

• Staffing, Talent Recognition - Talent Manager в компании Blockchain Works, 1 подтверждение

• Startup Development - Lead Technical Recruiter в компании Abacus Works, 1 подтверждение

• Onboarding - Senior Technical Recruiter в компании Branch, 1 подтверждение

• Sourcing - Опыт работы (3) в компании Abacus Works и еще в 2 компаниях, 1 подтверждение

• Talent Mapping - Опыт работы (3) в компании Branch и еще в 2 компаниях

• Technical Recruiting - Опыт работы (4) в компании Abacus Works и еще в 3 компаниях, 4 подтверждения

• Internet Recruiting - 27 подтверждений

• Consulting - 14 подтверждений

• Talent Acquisition - Опыт работы (2) в компании Branch и еще в 1 компании, 12 подтверждений

• Financial Services - 6 подтверждений

• HR Consulting - 10 подтверждений

• Recruiting - 18 подтверждений

• И т. д. (всего 28 навыков).

Eda Akturk:

829 отслеживающих. Последняя публикация была 1 месяц назад. Она получила 103 реакций и 11 комментариев. Классно, что про компанию пост.Предпоследняя публикация была размещена 4 месяца назад. Она получила 15 реакций.

Опыт работы:

• Developer Advocate в Abacus Works с сентября 2024

• Technology and Innovation Consultant в The World Bank с мая 2023 по июнь 2024 (контракт)

• Developer Relations  в Ethereum Foundation с августа 2022 по апрель 2023 (контракт, удалённая работа)

• В Cisco: Associate System Engineer с августа 2019 по июль 2020, Technical Solutions Specialist с августа 2020 по январь 2022

• В GE Healthcare: EGM/SHS Service Analytics Intern с августа 2017 по февраль 2018 (Стажировка), EGM Service Analytics Specialist с февраля 2018 по июль 2019

• В Koç University: Exchange Student Mentor с сентября 2016 по июль 2017, Exchange Student Board Mentor с августа 2017 по июнь 2018

• Business Analyst Intern  в ASEE в июле 2017

• Software Developer Intern - Microsoft Turkey Summer Camp в августе 2016

Образование:

Koç Üniversitesi: Bachelor of Science - BS, Computer Engineering с 2014 по 2018, Bachelor of Arts - BA, Economics с 2016 по 2019

Навыки:

• Microsoft Office - Подтверждения навыков от участника Abdulla AlHelou, который является специалистом в этой области, Подтверждения навыков от 2 коллег по компании Cisco, 9 подтверждений

• Customer Service, Microsoft Excel - Подтверждения навыков от 2 коллег по компании Koç Üniversitesi, 2 подтверждения

• agement - 2 подтверждения

• Project Management - 6 подтверждений

• Microsoft Word, PowerPoint, Research, Public Speaking - 2 подтверждения

• Leadership - 7 подтверждений

• Computer Engineering - 5 подтверждений

• Cisco Certified

• Amazon Web Services (AWS) - Оценка навыков LinkedIn успешно выполнена

• Python (Programming Language)

Начну с пустых профилей...

Works Abacus:

0 отслеживающих. Ни навыков, а в опыте работы только должность в Hyperlane: управляющий директор... Есть небольшие сомнения, что это тот, но другого с похожим описанием аккаунта в поиске не нашёл...

И второй - Chan Lee:

1 отслеживающий, в опыте работы только компания проекта с должностью исполнительный директор, больше ничего нет...

Avi Atkin:

3569 отслеживающих. Последняя публикация две недели назад. Она получила 16 реакций и 3 комментария. Статья была не про Hyperlane, но про блокчейн сферу...

Опыт работы:

• В Abacus Works: Product Manager с июля 2023 по август 2024, Product Lead, Ecosystem Growth с августа по октябрь 2024

• Product Manager в 3Box Labs с апреля 2022 по июль 2023

• Product Manager, Autonomous Vehicles в Ford Motor Company с ноября 2017 по август 2021

• 2016 Venture for America Fellow в Venture For America с июля 2016 по июнь 2018

• Data Lead в Roadtrippers с августа 2016 по август 2017

Образование:

Baruch College: Bachelor of Business Administration (B.B.A.), Computer Information Systems

Навыки (всего 31 - покажу с подтверждениями):

• Product Design - 7 подтверждений

• User Experience - 4 подтверждения

• Social Media - 67 подтверждений

• Marketing Strategy, Social Entrepreneurship - 1 подтверждение

• Strategic Planning - 18 подтверждений

• Market Research - 10 подтверждений

• Event Planning - 20 подтверждений

• Writing - 4 подтверждения

• Financial Modeling - 1 подтверждение

• WordPress - 16 подтверждений

• И другие (все равно много получается...)

Connor McEwen:

1421 отслеживающий. Последняя публикация 6 месяцев назад, которая получила 103 реакции, 10 комментариев и 2 репоста.

Опыт работы:

• VP of Engineering (Вице-президент по инжинирингу) в Abacus Works с мая 2024

• Director of Engineering в Uniswap Labs с августа 2021 по май 2024

• Partner, Engineering в cLabs с марта 2018 по август 2021

• Самозанятый Консультант по разработке программного обеспечения с марта 2017 по март 2018

• Lead Engineer, Emerging Products в GoDaddy с декабря 2015 по май 2017

• Software Engineer в Wildcard Inc с сентября 2014 по декабрь 2015

• Boston Investment Team в Dorm Room Fund с октября 2013 по май 2014

• Business Analyst в Boston University Office of Technology Development с июня 2013 по май 2014

• Co-Founder в Credport с мая 2012 по май 2013

• Research Assistant в Boston University Multimedia Communications Laboratory с февраля 2011 по январь 2012.

Образование:

Boston University: Bachelor of Science (BS), Computer Engineering2010 - 2014

Навыки:

• Start-ups - Подтверждения навыков от участника Rene Reinsberg, который является специалистом в этой области, Подтверждения навыков от 2 коллег по компании Wildcard Inc, 21 подтверждение

• Mobile Applications - Подтверждения навыков от участника Michael Healy 麦克李, который является специалистом в этой области, Подтверждения навыков от 3 коллег по компании Boston University, 16 подтверждений

• Mobile Devices - Подтверждения навыков от 2 коллег по компании Boston University, 15 подтверждений

• Entrepreneurship - 12 подтверждений

• Product Management, Product Development, Software Development - 7 подтверждений

• И другие... Всего 29.

Anthony Spezzano:

1056 отслеживающих. Последняя публикация вышла 1 день назад, и получила 3 реакции, 1 комментарий и 1 репост.Предыдущая была опубликована две недели назад. Она получила 9 реакций.

Опыт работы:

• Head of Business Development в Abacus Worksс августа 2023

• В Figment: Senior Protocol Analyst с мая по декабрь 2022, Principal Portfolio Analyst с декабря 2022 по август 2023

• Business Process Consultant в TD с марта 2021 по апрель 2022

• Risk Management Analyst в TD Securities с июля 2017 по март 2021

Образование:

York University: Bachelor's degree, Cognitive Science

Навыки:

• Personal Finance - 7 подтверждений

• Computer Proficiency - 8 подтверждений

• First Aid - 6 подтверждений

• CPR Certified - 4 подтверждения

• Personal Budgeting - 2 подтверждения

• И другие (всего 28).

Также я из статьи про инвестиции в проект узнал имена и фамилии сооснователей: рассмотрим их.

Asa Oines:

374 отслеживающих. Публикаций нет.

Опыт работы:

• Co-Founder в Abacus Works с августа 2022 по сентябрь 2023 (получается возможно уже не работает тут)

• Engineering в cLabs с марта 2018 по декабрь 2021

• Software Engineer в Google с августа 2015 по март 2018

• Software Engineering Intern в Google с июня по август 2014

• Hardware Engineering Intern в Apple с июня по август 2013

• Software Engineering Intern в Google с июня по август 2012

Образование:

1. Massachusetts Institute of Technology: Master of Engineering - MEng, Computer Science с 2014 по 2015

2. Massachusetts Institute of Technology: Bachelor of Science - BS, Computer Science с 2010 по 2014

Навыки не указаны.

Jon Kol:

1070 отслеживающих, публикаций нет.

Опыт работы:

• Chief Executive Officer в Abacus Works с марта 2022

• Managing Director в Galaxy с сентября 2019 по март 2022

• Investment Team в Passport Capital с февраля 2018 по сентябрь 2019

• Fixed Income Analyst в Morgan Stanley с июня 2016 по февраль 2018

• Summer Analyst в Morgan Stanley с июня по август 2015

• Corporal в Israel Defense Forces с 2008 по 2010

Образование:

University of California, Berkeley: Bachelor's degree, Economics

Навыки:

• Research - 3 подтверждения

• Valuation, Data Analysis - 2 подтверждения

• Microsoft Excel, Public Speaking - без подтверждений

• Municipal Bonds, Corporate Bonds, Fixed Income - 1 подтверждение

Nam Chu Hoai:

724 отслеживающих. Последняя публикация 8 месяцев назад с 19 реакциями и 3 комментариямиПредпоследняя - 2 года назад: 128 реакций и 17 комментариев.

Опыт работы:

• Co-Founder / CTO в Abacus Works с апреля 2022

• Software Engineer в cLabs с августа 2018 по март 2022

• Software Engineer в Wellframe с июня 2014 по январь 2018

• GEIR в Venture Development Center at UMass Boston с сентября 2016 по май 2017

• Фрилансером был Fullstack Web Developer с июня 2014 по август 2015

• И другое (всего - 12).

Образование:

Boston University: Bachelor of Arts (B.A.), Computer Science2010 - 2014

Навыки (всего 30 - покажу лишь часть):

• Entrepreneurship - Подтверждения навыков от участника Stefan Jørgensen, который является специалистом в этой области, Подтверждения навыков от 3 коллег по компании Wellframe, 10 подтверждений

• Web Development - Подтверждения навыков от 2 коллег по компании Wellframe, 8 подтверждений

• HTML 5, Venture Capital - 3 подтверждения

• Programming - 2 подтверждения

• И другие (всего 30)

У большинства из представленных хороший опыт и навыки, а некоторые работали в известных компаниях, например, Meta и Microsoft.

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

X (twitter) @hyperlane:

77,4 тысяч читателей, 2499 постов.

Последний пост был 14 часов назад. Он получил 23 ответа, 110 репостов, 380 лайков, 16844 просмотров.Предыдущий вне треда - 18 часов назад. Получил 19 ответов, 112 репоста, 480 лайков и 75015 просмотров.

Аудит по tweetscout:

Score 1072, уровень 4 (Significant).

Проекты: DEGEN NEWS, Circle, Alchemy, Layer3, CC2, Everclear (prev Connext), Fuel, L2BEAT, Gelato, WOO X, Moonbeam Network и другие...

Венчурный капитал: loomdart - Holy War Arc, eGirl Capital 仙女資本, DeFi Dad ⟠ defidad.eth, Fourth Revolution Capital, Jesse Walden, Variant и другие...

Афеллированные аккаунты:

Участники команды и другие...

Discord:

В анонсах последний пост сегодня.

В основном чате активность есть, на вопросы отвечают, и корректно:

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

В Русском чате активность тоже есть, да и на мой вопрос ответили:

История ушла вперёд, поэтому показываю ответ на свой вопрос отдельно:

Тикетов здесь нет, но есть суппорт-форум:

Оценка 4 из 5: LinkedIn конечно на сайте нет, да и ссылки не у всех есть, но через поиск можно найти сотрудников, и у них хороший опыт работы с навыками, поэтому лишь минус один балл.

Hyperlane — это первая в своем роде безразрешительная (permissionless) интероперабельная платформа, которая предоставляет возможность для соединения различных блокчейнов в одном пространстве. Она позволяет разработчикам смарт-контрактов обмениваться произвольными данными между сетями, создавая единую экосистему для межцепочных приложений (interchain applications), доступных пользователям на любой поддерживаемой блокчейн-платформе.

Основная концепция Hyperlane — это создание гибкого и настраиваемого интероперабельного фреймворка, который охватывает более 70 различных блокчейнов и поддерживает свыше 5 виртуальных машин (VMs). Это позволяет проекту соединять любые чейны без необходимости ожидания поддержки от сторонних провайдеров моста, так как Hyperlane предоставляет возможность самостоятельного развертывания (DIY) на любом блокчейне. Такой подход обеспечивает масштабируемость и значительно ускоряет процесс интеграции новых сетей.

Hyperlane реализует модульную архитектуру безопасности, что позволяет разработчикам выбрать подходящий модуль безопасности для своих нужд с помощью Interchain Security Modules (ISMs). Эта система позволяет применять свои валидаторы, устанавливать лимиты по скорости передачи данных и задействовать экономическую безопасность на сумму более $5 миллиардов через Hyperlane AVS. Доступность различных моделей безопасности делает Hyperlane подходящим решением для различных уровней требований к безопасности.

Одним из ключевых преимуществ Hyperlane является функциональность Warp Routes, которая обеспечивает мгновенные и без-слиппеджевые (no-slippage) транзакции для обмена токенами между чейнами. Warp Routes позволяет пользователям подключать любые токены с низкими комиссиями и высокой скоростью, что делает процесс удобным и доступным.

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

1. Deploy Hyperlane — настройка протокола Hyperlane на выбранной сети для отправки и получения сообщений внутри сети.

2. Create Warp Route — создание маршрутов для обмена токенами через командную строку.

3. Launch Warp UI — запуск пользовательского интерфейса, который позволяет пользователям взаимодействовать с созданными маршрутами, обеспечивая простоту использования и удобство для конечных пользователей.

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

Источник: обзор протокола в документации и главная страница.

В DefiLlama проекта нет, но нашёл несколько Dune дашбордов.

Первый - anonvee/hyperlane-leaderboard-rank:

Здесь можно посмотреть рейтинг кошельков по количеству транзакций (считаю бесполезными данными).

Вторая таблица позволяет посмотреть рейтинг по объёмам в tia.n на Trader Joe.

danrechi/hyperlane-stats:

Интересно, что

• общая сумма собранных комиссий по данным дашборда $3,070,996.

• Всего 252,939 транзакций с Superform, использующих Hyperlane

• Пользователей - 613,272

• Также можно посмотреть таблицу лидерборда по количеству транзакций

• Не пойму, что означает процесс транзакций, но значение тут 3,978,572

• Есть также анализ вовлечённости пользователей (график) на основе количества транзакций на пользователя

realpeha/hyperlane:

Здесь:

• График средних сборов Hyperlane

• Количество транзакций назначения в каждой сети (график)

• Также есть количество пользователей - 613,908

• И рейтинг по количеству транзакций

• График уникальных пользователей за день

• График новых пользователей

• Среднее число транзакций - 3

• Таблица поддерживаемых блокчейнов (показано 43). Здесь можно узнать название, domain id и есть ли полная поддержка

• Общая комиссия по блокчейнам (график)

• График количества исходных транзакций по блокчейнам

• Пишут, что всего собрано комиссий на $3,050,235

• количество транзакций на одного отправителя (таблица) по проектам на Hyperlane.

• среднее время доставки (график)

• совокупное количество транзакций (график)

• Средний показатель txsHyperlane: статистика - 7

• Количество транзакций по дням (график)

• Общее количество сообщений на Hyperlane: 5,325,081

• 4,324 отправителя (как понимаю речь про смарт-контракты)

• количество транзакций на маршрут (график)

• Дневные комиссии по блокчейнам (график)

Оценка 4 из 5: Идея интересная, аналитика пусть и не очень существенную активность показывает, но тем не менее уже и немалую... Но ещё неизвестно, как протокол себя покажет, сможет ли конкурировать с существующими, поэтому 4 из 5.

Токеномики нет, но есть инвестиции в проект по данным Cryptorank:

Вложили 18,5 МЛН $ Circle, Variant, CoinFund, Kraken Ventures, Figment Capital, NFX, Blockdaemon Ventures и Galaxy Ventures.

Оценка 3 из 5: инвестиции хорошие и от нескольких инвесторов, но токеномики и ютилити нет.

Есть Github репозитории:

Их 38, поэтому показывать буду некоторые (которые посчитаю основными).

hyperlane-xyz/hyperlane-registry:

Коллекция конфигураций, артефактов и схем для Hyperlane. Дополнительную информацию смотрите в документации.

Последний коммит (обновление) 5 часов назад:

Всего - 338 коммитов:

Хорошая активность в плане разработки... Добавляют и новые функции, и функции добавляют / изменяют.

hyperlane-xyz/hyperlane-monorepo:

База для контрактов Hyperlane core, пакетов sdk и другой инфраструктуры

Последний коммит 42 минуты назад:

Всего - 2,789 коммитов:

Тоже активная разработка...

hyperlane-xyz/hyperlane-explorer:

Веб-приложение для Hyperlane Explorer

Последний коммит был вчера:

Всего 433 коммита:

Менее активно развивают, тем не менее коммиты периодически выпускают.

hyperlane-xyz/hyperlane-warp-ui-template:

Шаблон веб-приложения для создания пользовательских интерфейсов Hyperlane Warp Route

Последний коммит был 3 дня назад:

Всего 234 коммита:

Периодически обновляют, что здорово.

Есть и аудиты кода:

Рассмотрим 3 из указанных аудита:

1. Hyperlane V3 (Trail of Bits): Аудит V3 показал высокий уровень безопасности, без критических уязвимостей. Все выявленные проблемы были устранены. Основные рекомендации касались улучшения качества кода и поддержки актуальности документации. Тесты и механизмы проверки были признаны адекватными, но для обеспечения безопасности предложено провести более углублённый аудит, так как найденные в ходе аудита мелкие уязвимости (например, потенциальная двойная трата) могут критически влиять на протокол. Потенциальная двойная трата, кстати, была исправлена до завершения аудита.Протокол получил умеренные оценки за управление сложностью и документацию, из-за высокой сложности нового кода и долгих цепочек вызовов .

2. Hyperlane V2 (Hacken): В ходе аудита V2 были выявлены две средние и две низкие уязвимости. Уровень безопасности проекта оценён на 8 из 10, а общая оценка составила 8.6. Основные проблемы касались обновляемости (необходимость устранения ошибок в конфигурациях для предотвращения потерь данных) и соблюдения лучших практик. Общая кодовая база оценена положительно, с полной тестовой покрытостью .По состоянию на второй аудит, проведённый в апреле 2023 года, все критические и высокие уязвимости были устранены. Из двух средних и двух низких уязвимостей большая часть также была исправлена, включая вопросы безопасности обновляемости.

3. Hyperlane cw (Oak Security): В ходе аудита функционала CosmWasm (cw) были найдены несколько уязвимостей средней и низкой тяжести. Проблемы касались устойчивости к атаке отказа в обслуживании (DoS), недостатка проверок входных данных и неэффективности некоторых операций. Аудиторы отметили высокую сложность и предложили улучшить структуру дерева Merkle, оптимизировать проверки и обработку данных. Состояние документации и тестов было признано средним, что может требовать доработок .Часть выявленных проблем также была решена. Например, решены проблемы с отсутствием валидации входных данных и неэффективностью Multisig ISM. Некоторые рекомендации, такие как оптимизация структуры дерева Merkle и улучшение обработки данных в Multisig ISM, были признаны проектом, но не исправлены полностью, поскольку клиент планировал управлять параметрами в операционной среде

Оценка 5 из 5: активная разработка, наличие нескольких аудитов разных частей кода, его открытость - в общем, отлично!

Сайт: https://docs.hyperlane.xyz/

Рассмотрим все разделы.

Введение в Hyperlane

Что такое Hyperlane?

Hyperlane — это кроссчейн-протокол для взаимодействия между сетями без разрешений. Он обеспечивает передачу сообщений и перемещение активов между разными сетями без необходимости в централизованных посредниках или дополнительных разрешениях.

Почему стоит выбрать Hyperlane?

Модель Hyperlane, не требующая разрешений, позволяет любому пользователю развернуть Hyperlane в любой блокчейн-среде, будь то первый уровень (layer 1), роллап или специализированная сетевая платформа (app-chain), и сразу приступить к созданию кроссчейн-приложений — без согласований и посредников. Это даёт разработчикам полный контроль над тем, как их децентрализованное приложение функционирует в мультичейн-среде, устраняя узкие места и улучшая масштабируемость.

Hyperlane был разработан с учетом модульности: его Интерчейн-модули безопасности (ISM) позволяют разработчикам настраивать, комбинировать и адаптировать модель безопасности в соответствии с потребностями их приложений.

Начните разрабатывать с Hyperlane

Некоторые предварительно разработанные примеры, которые можно развернуть сразу, включают:

1. Warp-маршруты — позволяют нативным токенам и токенам ERC20 перемещаться между сетями без препятствий.

2. Интерчейн-аккаунты — позволяют аккаунту в одной сети (например, DAO) выполнять ончейн-вызовы смарт-контрактов в удаленных сетях.

3. Интерчейн-запросы — позволяют аккаунту в одной сети выполнять оффчейн-запросы для получения данных в удаленных сетях.

Как соединить вашу сеть с Hyperlane:

Этот гайд поможет вам как можно быстрее развернуть Hyperlane в вашей новой сети для тестирования, а не для продакшена. В него входят основные контракты почтового ящика (mailbox) и ISM, а также контракты warp-маршрутов для активов, которые вы перемещаете.

Чтобы узнать, какие сети уже поддерживаются, посетите Registry. Если вам потребуется помощь, обращайтесь в канал #developers на Discord или свяжитесь напрямую.

Для интеграции понадобится ID блокчейна, его имя и RPC, а также приватный ключ кошелька-деплоера/EOA или seed-фраза (этот EOA должен быть профинансирован как в вашей кастомной сети, так и в любой сети, с которой будет осуществляться обмен сообщениями) и Hyperlane CLI.

Далее идёт инструкция с командами и конфигами, которая не всем будет понятна / интересна, поэтому её пропущу. При желании можете изучить, зайдя на страницу.

Интересно то, что после запуска просто делаете PR (пул-реквест), и сеть будет добавлена, если всё правильно в нём указано, и функционал Hyperlane с вашей стороны работает.

Если возникли неполадки при деплое сети, изучайте соответствующую страницу (я её описывать не буду).

О переходе к производству (продакшену) (целый раздел про это написан).

Перейдём к разделу для разработчиков смарт-контрактов. Я тут покажу тоже только одну страницу в качестве примера - Как создать мост для токена с помощью Hyperlane Warp Routes:

Создайте кроссчейн-мост для токена без необходимости разрешений, развернув контракты Hyperlane Warp Route.

Предварительные требования: Hyperlane CLI и Приватный ключ для подписания транзакций контрактов

Подробности опустим, т. к. они многим неинтересны.

После завершения деплоя переходите к развёртыванию интерфейса моста.

Интересно, что можно создать Warp-маршрут с доходностью благодаря интеграции с ERC-4626, которую распределять между основателем моста и пользователями.

Чтоб облегчить пользователям вашего L-2 (если он есть) взаимодействие без ожидания 7 дней вывода в L-1 для передачи в другой L-2, можно создать Warp-маршрут быстрых собственных переводов с помощью пользовательских Газовых токенов.

Если у вас уже есть Warp-маршрут, можете его расширить в новый блокчейн.

Кстати, Hyperlane поддерживает и SVM чейны, например, Solana. Вот инструкция по деплою WARP-маршрута SVM.

Также в разделе для разработчиков смарт-контрактов есть страница по созданию своего собственного хука & ISM для взаимодействия с другими протоколами или иного...

В советах для разработчиков дана информация по юнит-тестам, а также источникам и кранам токенов.

Далее - для агентов операторов.

Быстрый старт: запуск валидатора:

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

Для более подробной информации ознакомьтесь с гайдом по валидаторам.

Терминология

"Локальная сеть" — это ваша новая сеть, на которую вы хотите развернуть Hyperlane.

"Удаленная сеть" — это сеть с уже существующим развертыванием Hyperlane, с которой ваша локальная сеть будет отправлять и получать сообщения.

Запуск валидатора

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

Саму установку не буду описывать: долгая и сложная...

Также есть инструкция по запуску релеера (ретранслятора):

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

Для более подробной информации ознакомьтесь с гайдом по релеерам.

https://t.me/denis_skripnik

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

Mailbox:

Смарт-контракты Hyperlane Mailbox предоставляют on-chain API для отправки и получения кроссчейн-сообщений. Контракт Mailbox развернут в каждой сети, которую поддерживает Hyperlane.

Сеть Mailbox обеспечивает связь между блокчейнами, которую разработчики используют для создания кроссчейн-приложений и добавления кроссчейн-функционала в свои существующие приложения.

Для отправки сообщений надо вызывать функцию dispatch, а для получения - handle:

• dispatch(destination, recipient, body)

• handle(origin, sender, body)

Каждое сообщение обладает своим nonse, который уникален для каждого mailbox.

Структуру сообщения пропустим и некоторую другую информацию, т. к. она особо не важна, а перейдём к описанию процесса отправки сообщения.

Чтобы отправить кроссчейн-сообщения, разработчики вызывают Mailbox.dispatch().

Эта функция принимает в качестве параметров содержимое сообщения, ID целевой сети и адрес получателя. Каждое сообщение вставляется как лист в инкрементальное дерево Меркла, хранящееся Mailbox.

Протокол Hyperlane с доказательством доли использует это дерево Меркла для проверки доказательств мошенничества.

Process

Чтобы доставить кроссчейн-сообщения, релеер вызывает Mailbox.process().

Эта функция принимает в качестве параметров сообщение для доставки, а также произвольные метаданные, которые может указать релеер.

Mailbox передаст сообщение и метаданные модулю безопасности целевой сети для проверки. Если ISM успешно проверяет сообщение, Mailbox доставит сообщение получателю, вызвав recipient.handle().

Следующие страницы с подробностями по отправке и получению сообщений описывать не буду. Скажу лишь, что функция handle должна быть ограничена адресом Mailbox, если контракт должен принимать вызовы только от кроссчейн-сообщений, но это есть в библиотеке.

Кроссчейн платежи за Газ:

Успешные кроссчейн-сообщения требуют выполнения двух транзакций: одной в исходной сети для отправки сообщения и одной в целевой сети для доставки сообщения.

Для удобства Hyperlane предоставляет on-chain интерфейс в исходной сети, который позволяет отправителям сообщений оплачивать сборы релееру за доставку сообщения в целевую сеть. Эта оплата называется кроссчейн-газовой оплатой.

Кроссчейн-газовые платежи осуществляются с помощью смарт-контрактов InterchainGasPaymaster (IGP).

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

Каждый контракт InterchainGasPaymaster соответствует ровно одному релееру. Адреса релееров Abacus Works можно найти в разделе адресов.

Кроссчейн-газовый платеж рассчитывается следующим образом:

gasLimit и exchangeRate настраиваются отправителем сообщения и релеером соответственно.

Лимит газа устанавливается на основе стоимости вызова функции handle в целевой сети для данного сообщения. Это может варьироваться в зависимости от содержимого сообщения и логики обработчика. Отправитель сообщения должен настроить лимит газа на основе ожидаемых затрат на обработку сообщения, при этом используется значение по умолчанию, если лимит газа не настроен.

См. справку по хуку кроссчейн-газов для получения более подробной информации.

Post-Dispatch хуки:

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

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

Подробности опустим, т. к. они нужны лишь разработчикам.

Интерчейн-Газовые платежи:

Для доставки сообщения транзакция должна быть включена в целевую сеть, которая вызывает функцию process Mailbox с закодированным сообщением и метаданными ISM.

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

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

Подробности опустим.

OP Stack хук:

Оптимизм и другие OP Stack роллапы имеют свой собственный интерфейс для передачи сообщений между L1 и L2, называемый CrossDomainMessenger. Сообщения, передаваемые через этот интерфейс, получают выгоду от безопасности слоя расчетов роллапа.

Чтобы предоставить эту безопасность в качестве опции в Hyperlane, мы создали комбинацию хуков и ISM, которые могут быть прозрачно настроены для повторного использования нативного интерфейса OP Stack.

Смотрите страницу с адресами для адресов хуков и ISM.

Как это работает

OPStackHook отправляет messageId в L1CrossDomainMessenger, который регистрирует его как событие Optimism TransactionDeposited с депозитом ETH и данными сообщения, которые затем захватываются нодой роллапа. Нода роллапа вызывает предкомпилированный контракт L2CrossDomainMessenger с функцией relayMessage, которая, в свою очередь, делает вызовы к настроенному контракту OptimismISM, устанавливая messageId в отображении verifiedMessageId на оригинального отправителя L1 (то есть пользователя). Релеер передает только сообщение без метаданных, ожидая, когда нода Optimism выберет его и сделает запись в хранилище, после чего доставка сообщения подтверждается.

Хук Arbitrum L2 to L1:

Система Outbox в Arbitrum позволяет выполнять произвольные вызовы контрактов с уровня 2 (L2) на уровень 1 (L1) после оптимистичного периода оспаривания, т.е. сообщения, инициированные в сети L2, которые в конечном итоге выполняются на L1. Более подробную информацию можно найти здесь. Hyperlane может использовать систему Outbox для того, чтобы задействовать оптимистичную безопасность Arbitrum L2 (с 7-дневным периодом вывода и операционными доказательствами мошенничества) для защиты сообщений с L2 на L1 из любых роллапов Arbitrum Nitro. Был реализован ArbL2ToL1Hook и ArbL2ToL1Ism.

Как это работает

Примечание: Исходящие сообщения с L2 не могут обеспечить автоматическое выполнение на L1 в рамках протокола, поскольку Ethereum не предоставляет возможностей для запланированного выполнения через ноду L1.

ArbL2ToL1Hook отправляет закодированный вызов функции с идентификатором сообщения в предкомпилированный контракт ArbSys на L2. После ожидания периода вывода вы можете вызвать getOutboxProof() на L2 для получения доказательства меркле сообщения. С этого момента у вас есть два варианта:

• Вариант A. Вы можете вызвать функцию проверки ArbL2ToL1Ism через вызов mailbox.process() с доказательством и другими закодированными данными, что в свою очередь вызывает outbox.executeTransaction(), проверяя корректность отправителя сообщения и данных сообщения.

• Вариант B. Вы можете напрямую вызвать outbox.executeTransaction() с доказательством и другими закодированными данными. Однако вам потребуется сделать второй вызов функции проверки ArbL2ToL1Ism, чтобы доставить сообщение. Этот вариант также позволяет доставку значений сообщения в контракт получателя.

Подробности опустим. Главное суть передал.

Хук Polygon PoS:

Polygon PoS имеет свой собственный интерфейс для передачи сообщений между Ethereum и Polygon, называемый fx-порталом. Сообщения, передаваемые через этот интерфейс, получают выгоду от механизма синхронизации состояния Polygon.

Чтобы предоставить эту безопасность в Hyperlane, была создана комбинация Hook и ISM, которую можно прозрачным образом настроить для повторного использования интерфейса fx-портала.

Как это работает

Polygon FX-портал предоставляет контракты FxChild (FxChild.sol) и FxRoot (FxRoot.sol) в качестве основных контрактов, на которых работает мост. Он вызывает и передает данные на пользовательские методы в другой сети без необходимости создания маппингов.

Контракты FxChild и FxRoot предоставляются и поддерживаются командой Polygon. Вы можете найти адрес этих контрактов в репозитории fx-портала Polygon.

Контракт PolygonPosHook отправляет полезные нагрузки с использованием FxRoot. Валидационные ноды получат сообщение и передадут его в другую сеть. Подробную информацию о механизме синхронизации состояния можно найти в документации StateReceiver.

Адрес 0x0000000000000000000000000000000000001001 может вызывать функцию onStateReceive в контракте FxChild. Контракт FxChild вызывает processMessageFromRoot в абстрактном классе CrossChainEnabledPolygonChild, который реализует PolygonPosISM. CrossChainEnabledPolygonChild поддерживается OpenZeppelin.

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

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

Как это работает

1. Настройка (Configure)Hyperlane определяет набор заранее подготовленных ISM. Разработчики могут развертывать любые из этих контрактов "с полки" и настраивать их под свои параметры. Например, разработчики приложений, которые хотят повысить суверенитет над кроссчейн безопасностью, могут развернуть Multisig ISM, настроенный с валидаторами, выбранными из их собственного сообщества.

2. Композиция (Compose)ISM действуют как "безопасные лего". Разработчики могут комбинировать различные ISM, чтобы закодировать модель безопасности, которая наилучшим образом соответствует их потребностям. Например, разработчики приложений, которые хотят дополнительной безопасности, могут развернуть Aggregation ISM, требующий проверки как Multisig ISM, настроенного с валидаторами из сообщества Hyperlane, так и Wormhole ISM, который подтверждает, что кворум валидаторов Wormhole подтвердил сообщение.

3. Настройка (Customize)ISM полностью настраиваемы. Разработчики могут писать свои собственные ISM, адаптируя их под нужды своего приложения. Например, разработчики приложений могут создавать ISM, которые изменяют модели безопасности в зависимости от содержания сообщений. Сообщения высокой ценности и редкие (например, управление) могут проверяться моделью безопасности, которая ставит безопасность выше задержек и затрат на газ. Сообщения низкой ценности и более частые могут проверяться моделью безопасности, которая ставит приоритет на задержки и затраты на газ выше безопасности.

Получатели сообщений могут указывать свои собственные ограничения безопасности, указывая адрес модуля кроссчейн безопасности (InterchainSecurityModule). Эта реализация может быть настроена, скомпонована и адаптирована в соответствии с потребностями их приложения.

Диаграмма последовательности:

Следующая схема демонстрирует упрощенную последовательность проверки и доставки кроссчейн-сообщения на целевом чейне.

ИНФО

Если получатель не реализует ISpecifiesInterchainSecurityModule или recipient.interchainSecurityModule() возвращает address(0), будет использован ISM по умолчанию, настроенный на Mailbox, для проверки сообщения.

Это опущено в схеме последовательности для ясности.

Саму схему можете посмотреть на странице.

Переопределение ISM по умолчанию:

Разработчики могут указать или переопределить ISM по умолчанию, реализовав интерфейс ISpecifiesInterchainSecurityModule в своем приложении.

Конкретно этот интерфейс должен быть реализован в том же смарт-контракте, который реализует функцию handle().

Если ISM не указан или если указанный ISM является нулевым адресом, будет использован тот ISM, который настроен по умолчанию на Mailbox целевого чейна.

Подробности на странице.

Multisig ISM:

Проверка сообщений с использованием подписей валидаторов

Multisig ISM — это один из наиболее распространенных типов ISM. Эти ISM проверяют, что m из n валидаторов подтвердили действительность конкретного кроссчейн-сообщения.

Подробности о структуре на странице.

Routing ISM:

Разработчики могут использовать Routing ISM для делегирования проверки сообщений другому ISM. Это позволяет изменять модели безопасности в зависимости от содержимого сообщения или контекста приложения.

Этот ISM просто переключает модели безопасности в зависимости от чейна-источника сообщения. Простой пример использования заключается в применении различных наборов валидаторов для Multisig ISM для каждой сети.

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

Aggregation ISM:

Разработчики могут использовать AggregationISM для объединения безопасности от нескольких ISM. Проще говоря, AggregationISM требует, чтобы m из n ISM подтвердили подлинность конкретного кроссчейн-сообщения.

Разработчики могут настроить для каждой исходной сети набор из n ISM и количество ISM, необходимых для подтверждения сообщения. AggregationISM может агрегировать безопасность любых ISM. Например, пользователи могут развернуть Multisig ISM с собственным набором валидаторов и развернуть AggregationISM, который объединяет этот ISM с дефолтным ISM Hyperlane.

CCIP Read ISM:

Использование CcipReadIsm предоставляет разработчикам большую гибкость верификации кроссчейн сообщений. В конечном итоге каждый другой тип ISM может быть реализован как CCIP Read ISM, поэтому при создании новых типов ISM в будущем рекомендуется строить CCIP Read ISM, так как работа по интеграции с релейерами уже выполнена.

Однако стоит учитывать, что CCIP Read ISM вводит зависимость от внешнего (по отношению к блокчейну), но само размещаемого API. Если это является серьезным препятствием для вашего случая использования, возможно, стоит рассмотреть другие техники верификации сообщений.

Перед созданием CCIP Read ISM стоит ознакомиться со спецификацией CCIP Read. Спецификация описывает обобщенный протокол, который позволяет смарт-контрактам на совместимых с EVM чейнах запрашивать и использовать оффчейн данные.

Как это работает

Релейер будет постоянно слушать события Dispatch, генерируемые Hyperlane Mailbox. Когда сообщение отправляется и захватывается релейером, он запросит у назначения ISM информацию о том, как обработать сообщение и будет ли доставка успешной.

ИНФОРМАЦИЯ Переменная moduleType должна быть правильно установлена в вашем ISM, чтобы релейер знал, что это CCIP Read ISM. Чтобы убедиться, что это настроено правильно, вы можете унаследоваться от AbstractCcipReadIsm в @hyperlane-xyz/core.

Затем релейер вызовет функцию getOffchainVerifyInfo(bytes) на ISM с содержимым доставляемого сообщения. Эта функция должна отклоняться с ошибкой OffchainLookup, описанной в разделе интерфейса, описанного на странице.

Релейер запросит конечную точку, указанную в этом сообщении об отклонении, и передаст предоставленный ответ и оригинальное сообщение в функцию process(bytes, bytes) назначения Mailbox.

Переходим к общественным ISM.

• Wormhole ISM уже описывался кратко выше. Скажу лишь, что он ещё не реализован (по данным из документации), но будет работать следующим образом:Для принятия сообщения надо будет, чтоб 13 из 19 валидаторов Wormhole приняли его.

• Optimistic ISM также ещё разрабатывается. Позволит добавить безопасность за счёт проверки мошенничества с задержкой и без существенных затрат по Газу.

• Op Stack ISM используется, и уже описан в Op Stack хуке.

• Polygon PoS ISM используется вместе с хуком Polygon PoS для использования механизма синхронизации состояния Polygon с целью обеспечения безопасности сообщений, передаваемых между Ethereum и Polygon PoS chain. Подробности были описаны в Polygon PoS хуке.

• Arbitrum L2 to L1 ISM используется вместе с хуком Arbitrum L2 to L1 для использования безопасности Arbitrum rollup для сообщений, передаваемых с Arbitrum L2 на Ethereum. Подробности были описаны в соответствующем хуке.

Протокол Hyperlane отделяет транспортный уровень от уровня безопасности при кроссчейн-передаче сообщений. Для выполнения развертывания он полагается на оффчейн-агентов, которые отслеживают ончейн-активность и выполняют транспортные аспекты или аспекты безопасности протокола.

Эти агенты реализованы на языке Rust и распределяются в виде образов Docker и бинарных файлов.

1. Релейеры выполняют требования по транспортировке сообщений протокола. Они агрегируют оффчейн-метаданные безопасности для интерфейса IInterchainSecurityModule и доставляют сообщения их получателям.

2. Валидаоры обеспечивают безопасность протокола в рамках Multisig ISM или Hyperlane AVS, подтверждая действительность сообщений Mailbox и предоставляя свои подписи релейеру.

Релеер:

Релейер выполняет транспортный уровень протокола Hyperlane, доставляя сообщения от исходных до целевых чейнов. В зависимости от кроссчейн-секьюрити-модуля (ISM), указанного получателем, может потребоваться метаданные для подтверждения безопасности сообщения, такие как подписи валидаторов для Multisig ISM, меркле-доказательства, доказательства с нулевым разглашением и др. Поэтому перед попыткой доставки релейер собирает любые специфические для ISM метаданные.

Совет

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

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

Релейеры могут легко настраивать сообщения, которые они хотят обрабатывать. В настоящее время релейер поддерживает:

1. Черный и белый списки отправителей и получателей.

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

Хотя запуск релейера не требует разрешений, отправителю сообщения необходимо выбрать, какому релейеру платить за доставку. Интеграции Mailbox обычно по умолчанию оплачивают одного и того же релейера, но отправители сообщений могут отказаться от этого. Для удобства Hyperlane будет запускать открытый и настраиваемый агент релейера, реализованный как бинарный файл на Rust. Если вы хотите запустить свой собственный релейер, разработчики Hyperlane открыли исходный код бинарного файла здесь.

Запуск собственного релейера включает развертывание контракта IGP и поддержание курсов обмена токенов и цен на газ внутри него для точного расчета сборов за доставку сообщений.

Информация

Хотите запустить релейер? Следуйте гайду для релейеров.

Подробности не всем интересны, поэтому опустим (смотрите на странице).

Скажу лишь, что исторические и новые сообщения индексируются с помощью запросов событий контракта Mailbox через RPC. Оплаты газа также индексируются для подтверждения того, что отправители оплатили доставку, и определенные ISM используют дополнительные данные исходного чейна. Это касается Multisig ISM, который полагается на контракт Merkle Tree Hook, чтобы информировать релейера о том, какая подпись валидатора соответствует какому сообщению. Для каждого типа события (сообщения, IGP, вставка Merkle Tree) создается отдельная задача индексации.

Индексатор записывает данные в локальную базу данных (RocksDB) в качестве кэширования, а также для связи с задачей Submitter, которая периодически опрашивает базу данных для проверки наличия новых отправленных сообщений. Релейер отдает приоритет новым сообщениям перед старыми, предполагая, что старые сообщения с большей вероятностью уже были доставлены. Это означает, что при (пере)запуске создаются два указателя: один для прямого, другой для обратного движения, оба инициализируются на верхушке блокчейна и используют поле монотонно увеличивающегося nonce сообщений для итерации.

Похожий подход используется для индексации других событий, но некоторые из них не имеют номера последовательности и могут быть пропущены, если получены некорректные ответы RPC — что случается довольно часто. В связи с этим задача индексации сообщений отправляет идентификаторы транзакций, где были обнаружены события, другим задачам индексации, что гарантирует, что ни одно событие Hyperlane не будет пропущено, если оно произошло в рамках одной транзакции с вызовом Mailbox.dispatch().

Валидаторы:

Валидаторы работают в рамках Multisig ISM или Экономического Модуля Безопасности, выполняя функцию слоя безопасности протокола Hyperlane. Если используется другой ISM, валидаторы не требуются. Они несут ответственность за аттестацию сообщений, подписывая корень Меркла (также называемый контрольной точкой) при новых отправках в Mailbox. Подписи должны быть доступны для того, чтобы любой (обычно релейер) мог их получить и отправить вместе с сообщением на целевой чейн.

В отличие от многих других протоколов, Hyperlane не имеет установленного набора валидаторов. Каждый может запустить своего валидатора, если контракт-получатель указывает Multisig ISM, который включает их валидатор. Контрольные точки валидаторов являются общедоступными. Это гарантирует, что транспортный слой не требует разрешений, поскольку любой может получить подписи и вызвать Mailbox.process() для доставки сообщения. Релейер просто предоставляет удобный сервис для отправителей сообщений.

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

Hyperlane разрабатывает валидатор в виде бинарного файла, реализованного на Rust, который может легко запустить любой желающий. Оперативно валидаторы должны запускать этот бинарный файл и иметь доступ к RPC-поставщику или ноде для чейна, который они валидируют. Основатели надеются, что большинство валидаторов Hyperlane будут из существующего сообщества операторов нод каждого чейна.

Хотите запустить валидатор? Следуйте гайду для валидаторов.

Валидатор выполняет две основные задачи: индексатор для исходной цепочки и отправитель контрольной точки для публикации подписанных корней Меркла.

Подробности также опустим.

Хотя важно сказать, что если используется Hyperlane AVS, валидатор должен стать оператором AVS.

Варп-маршруты:

Разработчики могут использовать Hyperlane для безразрешительной развертки Warp Routes — контрактов, которые позволяют любым токенам ERC20, ERC721 или нативным токенам беспрепятственно перемещаться между чейнами.

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

Как и все приложения, построенные на Hyperlane, Warp Routes обладают настраиваемой безопасностью через Модули Кроссчейн Безопасности (Interchain Security Modules). Это позволяет развертывателям Warp Route настраивать и применять индивидуальные правила и ограничения, которым должен соответствовать кроссчейн токен.

Warp Routes могут быть развернуты между любым набором чейнов, на которых уже есть развертывания Hyperlane. Если вы хотите создать Warp Route, который включает чейн, на котором Hyperlane в настоящее время не развернут, не стесняйтесь задеплоить Hyperlane самостоятельно!

Архитектура Warp Route

Контракты Warp Route передают ценность между чейнами, блокируя токены залога на исходном чейне (так называемом залоговом чейне) и затем создавая обернутые токены на целевом чейне (синтетическом чейне). Диаграмма на странице предоставляет упрощённый план процесса создания вашего Warp Route и результирующего актива.

Каждый Warp Route состоит из одного контракта, развернутого на каждом чейне, между которым может перемещаться токен. Эти контракты используют Mailbox для отправки кроссчейн-сообщений друг другу.

Когда пользователь переводит токены с канонического исходного чейна на неконанический целевой чейн, их токены блокируются в контракте HypERC20Collateral, который отправляет сообщение на целевой чейн для создания обернутых токенов.

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

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

Warp Route Interface

:

Hyperlane Warp Routes используют интерфейс IHypERC20 токена. Токены Warp Route реализуют этот интерфейс, который расширяет стандартный интерфейс ERC20.

Solidity код смотрите на странице.

Деплоер Warp Route может по желанию указать модули кроссчейн безопасности (ISM), которые используются для проверки сообщений о кроссчейн-передачах. Это означает, что каждый Warp Route может иметь уникальную конфигурацию безопасности. Пользователи, переводящие кроссчейн токены, должны понимать предположения о доверии маршрута перед его использованием.

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

Чтоб развернуть Warp-маршрут, следууйте пошаговой инструкции.

Warp маршруты: типы:

Warp Routes представляют собой реализацию моста для токенов в Hyperlane, позволяя безразрешительное перемещение нативных, ERC20 и синтетических (новоразвернутых ERC20) активов между любыми чейнами через Hyperlane. В данном документе представлены детали всех типов маршрутов.

Обратите внимание, что этот документ не включает маршруты ERC721.

Я не буду подробно описывать их: просто перечислю:

1. Native Token Warp Routesобрабатывают передачу нативных газовых токенов (например, ETH на Ethereum или Arbitrum, MNT на Mantle) между различными чейнами. Прямой перевод нативных токенов без упаковки.

2. Collateral-Backed ERC20 Warp Routes позволяют передавать ERC20 токены между чейнами, блокируя их в качестве залога. Упаковывает существующие ERC20 токены в качестве залога для переводов, блокирует токены в контракте на исходном чейне, освобождает эквивалентные токены на целевом чейне, использует SafeERC20 для безопасных переводов токенов.

3. Synthetic ERC20 Warp Routes. создают новые токены на целевых чейнах, представляющие токены с исходного чейна.. Поддерживает постоянное общее предложение на всех чейнах, поддерживает пользовательские атрибуты токена (название, символ, десятичные знаки), выпускает новые токены на целевом чейне, сжигает токены на исходном чейне при возврате.

4. Все маршруты расширяют контракт TokenRouter, который предоставляет основную функциональность для переводов токенов.

5. FastTokenRouter расширяет TokenRouter и обеспечивает более быстрые переводы токенов через механизм ликвидности.

6. Специализированные расширения Warp Route: Быстрые переводы с коллатералом (FastHypERC20Collateral), Интеграция Vault (HypERC4626OwnerCollateral, HypERC4626Collateral), Токены, обеспеченные фиатом (HypFiatToken), Масштабируемые нативные токены (HypNativeScaled), Интеграция xERC20 (HypXERC20 & HypXERC20Lockbox).

Пример настройки и случай использования смотрите на соответствующей странице (я их описывать не буду).

Interchain Account Interface:

Разработчики могут использовать интерфейс Interchain Account для создания и управления аккаунтом на удаленном чейне из своего локального чейна. В отличие от общего обмена сообщениями, который требует от получателей реализации специфического интерфейса, Interchain Accounts (ICAs) позволяют разработчикам взаимодействовать с любым удаленным контрактом.

ICAs позволяют вам осуществлять удаленные вызовы из Чейна A в Чейн B с использованием роутера (InterchainAccountRouter). Вот как это работает:

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

• Вы можете закодировать свой вызов, который включает адрес назначения, данные вызова и msg.value для каждого вызова, сгруппированные в массив.

• Вы отправляете закодированный вызов на роутер Чейна A, который пересылается на роутер Чейна B.

• После декодирования вызовов роутер Чейна B проверяет, был ли вычисленный адрес уже развернут. Если нет, Hyperlane разворачивает контракт OwnableMulticall.

• Затем роутер выполняет многократный вызов на адрес ICA, который в свою очередь выполняет желаемый произвольный вызов на Чейне B.

Интерфейс Interchain Account присваивает каждому кортежу (uint32 origin, address owner, address remoteRouter, address remoteISM) уникальный адрес ICA. Отправитель является владельцем этого ICA на целевом чейне и может направлять его для выполнения произвольных функций через конечную точку InterchainAccountRouter.callRemote().

Для основных чейнов, поддерживаемых Hyperlane, вы можете использовать значения по умолчанию, установленные владельцем контракта роутера. См. раздел #overrides для получения информации о том, как выполнять вызовы на любой чейн.

Остальные подробности смотрите на странице.

Hyperlane CLI:

Hyperlane CLI — это официальный инструмент командной строки для развертывания контрактов Hyperlane на новых чейнах. Он также включает утилиты для взаимодействия с развернутыми контрактами и реестрами.

Установка

Совет: требуется Node версии 18 или новее.

Для глобальной установки CLI используйте команду npm install -g. Это сделает команду hyperlane доступной в любом месте вашего терминала.

# Установить с помощью NPM

npm install -g @hyperlane-xyz/cli

# Или удалить старые версии

npm uninstall -g @hyperlane-xyz/cli

Альтернативно, для выполнения отдельных команд вы можете использовать npx или dlx:

# Запуск через команду npx от NPM

npx @hyperlane-xyz/cli

# Или через команду dlx от Yarn

yarn dlx @hyperlane-xyz/cli

Использование

Чтобы просмотреть список доступных команд и их аргументов, выполните команду:

hyperlane --help

Некоторые общие параметры команд включают:

• --version: Отображает текущую установленную версию CLI.

• --registry: Устанавливает URI реестра для использования метаданных сети и адресов контрактов.

• --overrides: Устанавливает дополнительный путь для переопределений канонических данных реестра.

• log: Устанавливает формат логирования для CLI (по умолчанию "pretty").

• verbosity: Устанавливает уровень логирования для CLI (по умолчанию "info").

• key: Устанавливает ключ, который будет использоваться для подписания транзакций (по умолчанию переменная окружения HYP_KEY).

Реестры

По умолчанию CLI будет извлекать метаданные чейна и адреса контрактов из канонического реестра Hyperlane, но будет записывать новые конфигурации и развертывания в вашу локальную файловую систему. Для получения дополнительной информации см. страницу Реестры.

Есть также библиотеки. Я их подробно описывать не буду, т. к. они нужны лишь разработчикам. Просто перечислю:

• Mailbox Client предоставляет функции, которые позволяют подклассам легко отправлять сообщения через Mailbox переменную mailbox хранилища и разрешать доставку сообщений через onlyMailbox модификатор.

• Router. В этом шаблоне экземпляр контрактов приложения развертывается в каждой поддерживаемой приложением сети. Каждый экземпляр знает адреса экземпляров в других чейнах. Эти экземпляры используют Hyperlane для передачи информации и состояния между собой в удалённых сетях.

• TypeCasts

• Message

• Standard Hook Metadata

Как пользоваться Hyperlane Explorer:

Hyperlane Explorer может использоваться для поиска сообщений в любой сети с развертыванием Hyperlane. Можно подробнее ознакомиться с сообщениями, чтобы узнать больше о их свойствах и статусе. Сообщения к/от основных сетей можно искать по хешу транзакции, идентификатору сообщения или адресу отправителя/получателя. Для других сетей эксплорер можно настроить для поиска сообщений, предоставив конфигурацию сети.

Hyperlane Explorer поддерживает поиск сообщений с использованием следующих значений:

• Хеш транзакции, инициировавшей сообщение (origin tx)

• Хеш транзакции, доставившей сообщение (destination tx)

• Адрес аккаунта, который отправил исходную транзакцию

• Адрес аккаунта, который отправил целевую транзакцию

• Адрес отправителя сообщения

• Адрес получателя сообщения

• Идентификатор сообщения

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

Важно: По умолчанию эксплорер будет находить сообщения только в основных сетях Hyperlane. Чтобы просмотреть сообщения, отправленные на другие сети или полученные от них, ознакомьтесь с настройками PI Chains.

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

Настройка разрешённых чейнов:

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

Шаги для настройки:

1. Перейдите на главную страницу эксплорера и нажмите кнопку "Origin" (Исходная сеть) или "Destination" (Целевая сеть). Это откроет модальное окно выбора чейна.

2. В этом окне нажмите на иконку плюса в правом верхнем углу.

3. Отобразится форма, принимающая JSON или YAML, соответствующий схеме ChainMetadata.

Если предоставлена корректная конфигурация блок-эксплорера на основе Etherscan, Hyperlane Explorer будет использовать её для поиска необходимых сообщений. Если конфигурация не указана, будет использован RPC URL. Обратите внимание, что исследователи с API-ключами (даже бесплатными) работают быстрее и надежнее.

Примеры метаданных смотрите на странице.

Для получения примеров структуры метаданных чейна, можете ознакомиться с документами, предоставляющими примеры конфигураций, соответствующих схеме ChainMetadata. Это поможет правильно настроить необходимые параметры для работы с PI-чейнами.

GraphQL API:

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

Подключение к API

Для выполнения запросов к данным вы можете использовать любой предпочитаемый клиент или библиотеку GraphQL, подключившись к следующему URL:

https://api.hyperlane.xyz/v1/graphql

Используя GraphQL, вы сможете выполнять различные запросы для получения информации о сообщениях, состояниях транзакций и другой активности в системе Hyperlane. Примеры есть на странице.

Экономическая безопасность:

Информация:

Hyperlane стремится сделать мошенничество затратным. Стейкинг и слэшинг скоро будут реализованы, но на данный момент они еще не внедрены. Эта страница представлена только для информационных целей. Подробности могут измениться по мере совершенствования дизайна.

Стейкинг и слэшинг

Стейкинг и слэшинг позволяют добавить экономическую безопасность к Межцепочным модулям безопасности (ISM), которые зависят от подписей валидаторов, включая Multisig ISM и Optimistic ISM. Валидаторы Hyperlane могут по желанию участвовать в протоколе стейкинга Hyperlane. В дальнейшем, если эти валидаторы попытаются фальсифицировать или цензурировать межцепочные сообщения, их стейк и любой делегированный им стейк могут быть подвергнуты слэшингу.

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

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

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

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

Hyperlane AVS

:

Этот гайд поможет вам понять модуль AVS (Actively Validated Service) от Hyperlane, построенный на основе EigenLayer, протокола рестейкинга Ethereum.

На данный момент Hyperlane использует модель Proof of Authority для обеспечения безопасности, в которой доверенная группа валидаторов отвечает за поддержание безопасности. Однако, если какой-либо валидатор подписывает ошибочно или с злым умыслом, это не влечет за собой никаких последствий, так как у этих валидаторов нет экономической ставки. Это пробел, который модуль AVS предназначен для устранения.

AVS позволяет обеспечивать экономическую безопасность внутри протокола Hyperlane с минимальными затратами на создание новой сети валидаторов для каждого поддерживаемого чейна. Это достигается за счет использования общего пула стейкинга, который может обеспечить безопасность исходящих сообщений из и между роллапами. Основные участники этого процесса:

• Операторы - операторы EigenLayer, которые участвуют в AVS-сервисе Hyperlane и начинают валидировать исходящие сообщения из указанных сетей.

• Стейкеры - стейкеры EigenLayer, которые делегируют свой стейк операторам для обеспечения сети.

• Приложения - приложения, использующие Hyperlane, стремящиеся экономически обеспечить свои сообщения между чейнами.

Внимание: На данный момент слэшинг и выплаты вознаграждений для EigenLayer еще не активированы. В дополнение к AVS необходимо настроить подписи и валидацию в кроссчейн модуле безопасности (ISM).

Архитектура AVS

Ниже представлена диаграмма классов, описывающая архитектуру текущих контрактов модуля AVS. Ключевым моментом является поддержка паттерна "metaAVS" с интерфейсом IRemoteChallenger.

Остальное смотрите на странице.

Реализации альтернативных виртуальных машин

:

В то время как публичная документация Hyperlane в настоящее время сосредоточена на совместимости с EVM, основатели предлагают различные уровни поддержки для дополнительных экосистем. На данный момент эти экосистемы могут не иметь полной паритетности функционала или полной интеграции инструментов (например, поддержки TypeScript CLI). В настоящее время активно работают над расширением документации и инструментов для этих платформ. Если вам интересно создавать на основе этих технологий или приносить Hyperlane в другие новые экосистемы, можете связаться с основателями проекта в Discord.

• Реализация CosmWasm Hyperlane, реализованная и поддерживаемая командой Mitosis. Следуйте этому гайду по развертыванию на Cosmos appchain. Проект уже в сети Celestia, Stride и Neutron с июля 2024 года.

• Sealevel - это реализация Hyperlane v3 для Solana Virtual Machine, которая теперь работает на Solana и Eclipse, с дополнительными роллапами Solana, coming soon. Вы можете найти реализацию контракта Sealevel здесь.

• Протокол Hyperlane был реализован на Cairo для Starkware командой Pragma. Вы можете найти реализацию, находящуюся в разработке, здесь.

• Hyperlane был реализован в MoveVM командой Movement Labs. Вы можете найти реализацию, находящуюся в разработке, здесь. Эти контракты Move уже работают на тестовой сети Movement's M1.

• Найдите реализацию Sway от команды Hyperlane, находящуюся в разработке, здесь.

Если вас интересует больше информации о конкретной экосистеме или интеграции с ней, не стесняйтесь задавать вопросы в Discord.

Развернутые адреса

:

Можете их посмотреть на странице.

Идентификаторы домена

:

в этот список включены только развертывания в блокчейнах, которыми управляет Abacus Works (юридическое лицо основателей). Каждый может без разрешения развернуть Hyperlane в любом чейне — основатели создают реестр, чтобы отразить разрешенные развертывания сообщества.

Hyperlane использует уникальные идентификаторы для каждой поддерживаемой сети. Когда это возможно, идентификаторы доменов Hyperlane соответствуют идентификаторам блокчейнов EVM, но это не гарантировано, так как поддерживаются также не-EVM чейны.

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

Таблицу смотрите на странице.

Задержки:

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

Обратитесь к разделам на странице для конфигурации финальности блоков, используемой валидаторами Hyperlane.

Hyperlane Registries

:

Hyperlane может быть развернут в любой сети любым участником. Для того чтобы такие развертывания приносили пользу, их параметры должны быть известны. Реестры содержат метаданные сети, адреса контрактов и другую полезную информацию для взаимодействия с контрактами и инструментами Hyperlane. Канонический реестр поддерживается основной командой Hyperlane, и такие инструменты, как CLI и Explorer, могут использовать его данные.

Метаданные и артефакты для развертываний, выполненных основной командой Hyperlane, доступны здесь: https://github.com/hyperlane-xyz/hyperlane-registry.

Участники сообщества также могут добавлять свои развертывания в этот канонический реестр. Процесс добавления включает следующие шаги:

1. Сделать форк и клонировать репозиторий реестра.

2. Использовать CLI, указав флаг --registry с локальным путем к клонированному репозиторию.

3. Выполнить необходимые команды.

4. Запушить изменения в свой форк и создать pull-запрос.

Любой репозиторий на Github или локальный путь могут использоваться как пользовательский реестр, если они соответствуют структуре и схемам файлов канонического реестра. CLI поддерживает два аргумента командной строки для настройки используемого реестра:

• Флаг --registry устанавливает основной реестр (по умолчанию используется Github).

• Флаг --overrides задает дополнительный путь, позволяющий принудительно переопределить данные по умолчанию, например, для использования другого RPC URL в метаданных сети.

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

Как использовать, смотрите на странице (пример на node.js).

Также описаны инструкции по деплою:

1. Развертывание Hyperlane с помощью локальных агентов. Это руководство предназначено для продвинутых пользователей, которые в конечном итоге могут захотеть запустить агенты Hyperlane в среде, похожей на производственную. Оно будет охватывать основы того, как вручную настраивать и запускать агенты, но это не руководство по настройке продакшена.

2. Руководство по реализации Hyperlane для новой архитектуры сети: создание контрактов, агентов и приложений. Примеры на Solidity показаны.

Перейдём к ресурсам:

1. Описана отладка сообщений: ответы на вопросы о возникающих ситуациях.

2. Словарь терминов. Поскольку термины пояснялись в процессе документации, не вижу смысла описывать эту страницу.

3. FAQ. Ничего интересного, что бы не рассмотрели мы, нет.

4. И аудиты (ссылку на них давал в коде).

Обзор:

Hyperlane отделяет транспортный слой кроссчейн передачи сообщений от уровня безопасности. Для запуска развертывания протокол полагается на оффчейн-агентов, которые наблюдают за ончейн-активностью и выполняют либо транспортные, либо защитные функции.

1. Валидаторы Hyperlane — лёгкие оффчейн-агенты, ответственные за безопасность. Они отслеживают сообщения в Mailbox в исходной сети и, если нужно, подписывают корневое значение дерева Меркла, подтверждающее текущее состояние Mailbox.

2. Релееры выполняют транспортную функцию протокола, собирают метаданные безопасности оффчейн для интерфейса IInterchainSecurityModule и доставляют сообщения получателям.

Валидаторы обеспечивают безопасность протокола как часть Multisig ISM или Hyperlane AVS, подтверждая подлинность сообщений Mailbox и предоставляя свои подписи для релеера. Эти подписи хранятся и размещаются в общедоступных хранилищах (например, в S3), чтобы релееры и Interchain Security Modules могли их использовать. Валидаторы работают независимо, не требуют консенсуса друг с другом и не отправляют регулярные транзакции в сеть.

Для операторов, стремящихся поддерживать безопасность исходной сети, работа валидатором является важной функцией, содействующей децентрализации передачи сообщений в Hyperlane. Однако просто работа в качестве валидатора не гарантирует активное участие в защите сообщений: для этого Multisig ISM на целевой сети должен использовать ключ проверки подписи валидатора.

Валидаторы реализованы на языке Rust и распространяются в виде Docker-образов и исполняемых файлов.

👉 Подробнее о Валидаторах.

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

Релееры Hyperlane могут ретранслировать сообщения между несколькими исходными и целевыми сетями. Каждое сообщение требует выполнения двух транзакций:

1. Отправка сообщения в исходной сети.

2. Доставка сообщения в целевой сети.

Для выполнения своей задачи релеер:

• Отслеживает новые сообщения в исходной сети.

• Проверяет Interchain Security Module (ISM), указанный получателем, для получения необходимых метаданных безопасности (например, может извлекать подписи Multisig ISM из хранилища контрольных точек валидатора).

• После сбора метаданных релеер отправляет сообщение получателю на целевой сети.

Если доставка сообщения не удалась (например, из-за отсутствия ликвидности для выхода из контракта Warp Route), релеер повторяет попытку с экспоненциальным увеличением интервала до успешной доставки.

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

👉 Подробнее о Релеерах.

Для запуска валидатора Hyperlane требуется соблюдение нескольких технических условий:

1. Защищённый ключ подписиВалидаторы используют этот ключ для подписания последнего корня дерева Меркла Mailbox. Защита этого ключа крайне важна: его компрометация может позволить злоумышленникам подделывать сообщения, что приведёт к наказанию валидатора.В настоящее время агент валидатора Hyperlane поддерживает подпись с использованием ключей AWS KMS, доступных через API-ключи/секреты, а также ключей в шестнадцатеричном виде. Дополнительная информация доступна в разделе об агентских ключах (я его не стал описывать в связи со специфичностью).

2. Открытое хранилище для чтенияВалидаторы записывают свои подписи оффчейн в общедоступные и надёжные хранилища, чтобы релееры могли их собирать.Агент валидатора Hyperlane поддерживает хранение подписей в AWS S3, используя указанные выше API-ключи AWS, а также на локальной файловой системе для тестирования.Я считаю, что плохо это: лучше бы реализовали P2P сеть для передачи данных.

3. Проект с открытым исходным кодом допускает адаптацию для других решений хранения и ключей. В сообществе имеется незавершённый PR для поддержки GCS.

4. Сервер для запускаВалидаторы могут скомпилировать бинарный файл на Rust самостоятельно или использовать Docker-образ, предоставленный Abacus Works. Бинарный файл может быть запущен на любом облачном сервисе. Поддерживается развертывание нескольких экземпляров в разных регионах для высокой доступности, поскольку в Hyperlane нет понятия «двойной подписи».Минимальные требования к оборудованию и стоимости: валидаторы обычно запускаются на системе с 2-ядерным процессором, 2 ГБ оперативной памяти и 4 ГБ памяти, с ориентировочной стоимостью около $75 в месяц.

5. RPC-нодаВалидаторы выполняют простые вызовы для чтения корней дерева Меркла из Mailbox-контракта в сети, которую они проверяют. Необходимо использовать собственные URL-адреса RPC, а не общедоступные.

Внимание: для работы валидатором в сети Polygon mainnet требуется доступ к архивной ноде. Это связано с тем, что валидаторы должны подписывать корни только после достижения финальности, а для достижения финальности в Polygon требуется 256 подтверждённых блоков.

Сам гайд смотрите на странице.

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

Мониторинг и оповещение:

Информация о том, как получать уведомления и какие они бывают.

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

Требования

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

2. Ключи для подписания транзакцийРелейер должен быть настроен с использованием ключей для подписания транзакций на каждом целевом чейне (в этих сетях должны быть средства).Эти ключи используются для подписания транзакций, вызывающих метод Mailbox.process(). Релейер Hyperlane поддерживает использование ключей AWS KMS, доступ к которым предоставляется через API-ключи/секреты, или же простых шестнадцатеричных приватных ключей.

3. Сервер для запускаОператоры релейера могут либо скомпилировать бинарный файл на Rust самостоятельно, либо использовать Docker-образ, предоставленный Abacus Works.Бинарный файл можно запустить на облачных сервисах или других предпочитаемых платформах.

Остальную информацию смотрите на странице.

Фильтрация сообщений

:

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

Как это сделать, смотрите на странице.

Мониторинг и оповещение

:

Также можно настроить и получать уведомления. Информация о том, как это сделать, а также какие уведомления выдаются, смотрите на странице.

Конфигурация агента:

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

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

Подробности на странице.

А на странице Configuration reference можете посмотреть примеры файлов настройки.

В гайдах можно найти быстрый запуск с Докером, деплой с Terraform и гайд по оператору AVS.

Оценка 5 из 5: всё подробно и понятно. Жаль, что пока у проекта PoA используется, а это требует доверия к валидаторам сейчас. Но надеюсь, что запустят систему слешинга как можно скорее. Но поскольку к документации проблема эта не относится, минус балл не делаю.

На странице экосистемы вы не найдёте ссылок на приложения:

https://live.staticflickr.com/65535/54108023332_a98357813e_o.png

Но можете посмотреть блокчейны и их названия.

• Everclear - это бывший Connext, занимающийся чейн-абстракции, поэтому его в практике не будет.

• khalani - приложения нет

• Остальные рассмотрим.

А также:

1. Superform vault, в который стоит закинуть из Arbitrum. Возможно и другие хранилища поддерживают Hyperlane, но я не помню.Для подробного изучения советую прочитать обзор Superform.В практике подробно его рассматривать не буду.

2. Остальные рассмотрим (сами увидете, какие)...

"Connect Wallet":

Выбираем, подключаемся:

"Accept and Sign" и подписываем сообщение - всё:

Нажав на weETH, можно сменить токен (я сделал это на uniBTC, но потом вернул, т. к. его нет в Arbitrum):

Нажимаем по Ethereum:

И выбираем Arbitrum, например, и заполняем сумму:

"Deposit", одобряем расходование и подтверждаем транзакцию - всё:

Не вижу в инфе о транзакции использование Hyperlane... Возможно в будущем использовать будет, а возможно уже сейчас, но в фоне...

"Redeem" позволит вывести ликвидность:

Выбираем сеть отправки, нажав по "Cosmos Hub":

Выбираю тот же Arbitrum. Далее "Select Chain" и ввожу в поиске "Forma":

Выбирал её:

Токен получения выбран автоматически. Нажимаем "Connect Wallet":

Выбираем Cosmos кошелёк. Я выбрал Metamask - попросил поставить Snap и всякое такое... Результат:

"Connect EVM Wallet", выбираем и подключаем:

Нажимаю по ETH - появился список токенов.

Ввёл сумму - оказалось, что роут недоступен:

Выбрал TIA.n, обменяв на него предварительно, а вкачестве сети получения Cosmos Hub - получилось:

Правда в начале писал, что нужен NTRN: пришлось пополнять ATOM и менять на NTRN. В общем, для новых пользователей Cosmos экосистемы сайт бесполезен...

Нажимаю "Review swap":

"Confirm Swap" и отправляем транзакцию. Ждём 20 минут и идём в кошелёк:

Всё.

"Connect Wallet":

Выбираем тип кошелька (я - "Connect to Ethereum"):

Выбираю, подключаюсь и закрываю окно выбора кошельков. Результат:

Нажимаю по "On Ethereum" и выбираю сеть:

Выбрал Arbitrum.

"Select asset" и ввёл в поиске TIA:

Выбираю сеть:

Forma нет - выбрал Neutron. Ну и в сети отправки выбрал TIA.n, предварительно обменяв на него в swap.defillama.com. Сумму тоже указал:

"Swap". Тут "Set destination address":

Выбираю последний пункт:

"Confirm":

"Set recovery address", и также "Enter address manually", но ничего не меняется - адрес не принимает после нажатия по "Confirm".Оставлю: может у вас что обменять и получится...

"Connect wallet":

Выбираем тип сети (я Ethereum), сам кошелёк (подключил Metamask):

Заметьте: уже выбрана сеть отправки и получения, как в swapFast. Видимо как-то передают последний выбор... Хотя возможно это по умолчанию так...

Нажав по "neutron", можно выбрать другую сеть:

Выбрал Arbitrum.

Нажав в "To" по "arbitrum", меняю сеть:

"Select Token":

Выбираю "TIA.n". Ввожу сумму и адрес получателя:

"Continue":

"Send to Neutron" и подтверждаю в кошельке. Всё - ждём:

Можем скопировать id сообщения и вставить в explorer.hyperlane.xyz

Доставлено пишет. Нажмём по сообщению

Как видите, всё хорошо.

Подключение схоже:

Бридж тоже аналогичен предыдущему сервису:

Просто с конкретными сетями:

Я показывать уже это не буду.

Cryptorank bridge

Интерфейс stride стандартный для LST протоколов - показывать не буду. Да и статья о другом...

Нажимаем на странице моста "Connect Wallet":

Выбираете тип сети (я Ethereum):

Выбираем, подключаемся:

Можете добавить второй из Cosmos экосистемы, чтоб передавать туда активы:

Но Metamask здесь нет, чтоб использовать Snap от Leap wallet, поэтому пропущу...

Нажимаю по "Stride":

Поддерживаются только Celestia, Stride, Forma и Ethereum (он выбран в сети получения).

Кликнув по stTIA, можем выбрать токен, но он один доступен: показывать не буду.

Выбрал из Forma в Celestia:

Маршрут не поддерживается.

DsПодключил Leap (пришлось поставить расширение) и выбрал путь из Celestia в Forma, ввёл сумму и вставил адрес получателя:

"Bridge":

"Send to Forma" и подтверждаем в кошельке.

Нажав по транзакции можем увидеть, что всё успешно:

Всё.

"Connect wallet":

Выбираем, подключаем - результат:

Нажимаем по BSC и выбираем сеть:

Выбрал Base. Ввёл иную сумму:

"CLAIM":

Смотрим на комиссию и, если всё устраивает, нажимаем "Claim" и подтверждаем в кошельке.

После получения вставляем максимальный баланс. Я ещё изменил сеть получения:

"BRIDGE":

"Bridge" и подтверждаем в кошельке, если всё устраивает.

P. S. Не рекомендую злоупотреблять этим: поскольку число токенов неограниченное, это смахивает на сибильство (т. е. на накрутку ради аэрдропа).

"FREE MINT":

"MINT" и подтверждаем в кошельке, если всё устраивает.

Стала доступна вторая кнопка:

"BRIDGE":

"BRIDGE" и подтверждаем в кошельке.

Всё - ждём:

Не покажет обновлённый статус. Идём по ссылке "View in Hyperlane Explorer":

Готово.

Стандартный мост.

Жму по Arbitrum One:

Можно выбрать другую сеть, например, Op mainnet. Также выбрал и сеть получения другую (Scroll):

Ввёл сумму (комиссии большие), а также поменял местави сети через кнопку "Swap":

"Bridge" и подтверждаю в кошельке. Всё:

Можем убедиться, нажав по ссылке "Hyperlane Explorer":

Кликаем по времени сообщения:

Успешно.

Подобным Cryptorank app в плане этого функционала является merkly, поэтому его показывать не буду.

Приложение позволяет сминтить свой NFT и отправить через Hyperlane. Фишка в том, что вы создаёте свой уникальный NFT!

Нажимаем по кнопке сверху для раскрытия меню:

"Connect wallet":

Выбираем кошелёк и подключаемся.

Для создания NFT напишу название и описание.

"Auto-generate NFT Image" и жду. Нажав "Auto-generate" у названия и описания, можете сгенерировать их, но я оставлю свои.

"Get Mint" и подтверждаю в кошельке. Всё:

Можем отправить и твитнуть об NFT. Я нажимаю "Send" - появится кошелёк. Подтверждаем транзакцию - успешно:

По умолчанию отправляет в "Ancient8", в которой, кстати, нет токенов у меня.

Но можно выбрать другую сеть кликом по "Ancient8":

Кстати, нажав по кнопке меню, можем увидеть сеть:

А нажав по ней, выбрать другую:

Там же перейдём к "Bridge NFT":

И видим сминченное:

Можем перейти на его страницу:

Нажмём по "Arbitrum One$1.26":

И выберем другую. Я указал Gnosis:

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

Лидерборд:

Можете отслеживать себя тут, если интересно.

Плюс по сравнению с Cryptorank app в том, что создают похоже свой продукт.

Оценка 3 из 5: не везде поддерживаются все кошельки, роуты не зная заранее сложно подобрать, комиссии большие…

24 из 30 или 4 из 5.

• Команда: LinkedIn конечно на сайте нет, да и ссылки не у всех есть, но через поиск можно найти сотрудников, и у них хороший опыт работы с навыками, поэтому лишь минус один балл.

• Концепт: идея интересная, аналитика пусть и не очень существенную активность показывает, но тем не менее уже и немалую... Но ещё неизвестно, как протокол себя покажет, сможет ли конкурировать с существующими, поэтому 4 из 5.

• Коин: инвестиции хорошие и от нескольких инвесторов, но токеномики и ютилити нет.

• Код: активная разработка, наличие нескольких аудитов разных частей кода, его открытость - отлично, в общем!

• Документация: всё подробно и понятно. Жаль, что пока у проекта PoA используется, а это требует доверия к валидаторам сейчас. Но надеюсь, что запустят систему слешинга как можно скорее. Но поскольку проблема не относится к документации, минус балл не делаю.

• Практика: не везде поддерживаются все кошельки, роуты не зная заранее сложно подобрать, комиссии большие...

Благодарю за внимание. Писал статью 3 дня: буду рад распространению обзора и донатам.

С вами был незрячий программист, автор https://t.me/blind_dev - подписывайтесь на канал, чтоб получать новые обзоры, дайджесты статей из web3 сферы и новости по моим разработкам.