Резкая оценка дорожной карты «интернет-рынка капитала» Solana: шоу-копия, стремящаяся догнать Hyperliquid

🚀 Введение: Про SOLANA проводят встречу

Недавно в экосистеме Solana произошло нечто интересное. Включая фонд Solana, Anza, Jito Labs и других про, они собрались вместе, чтобы выпустить техническую дорожную карту под названием “Интернет Капитал Маркеты(Internet Capital Markets, ICM)”. Основная идея этой дорожной карты заключается в “Приложение Контролируемое Исполнение(Application Controlled Execution, ACE)”, проще говоря, это позволяет цепочечным приложениям иметь право на автономную сортировку транзакций на уровне миллисекунд, создавая децентрализованный “цепочечный Уолл-Стрит”.

Но интересно, что при чтении всей дорожной карты, хотя Hyperliquid не упоминается напрямую, дизайн почти повсюду нацелен на сильные стороны Hyperliquid. Это как если бы Solana говорила: “У вас, Hyperliquid, есть это, и у нас тоже будет, и мы сделаем это лучше!”

Следует отметить, что Hyperliquid занимает доминирующую позицию на рынке бесконечных контрактов на блокчейне, объем торгов в какой-то момент составлял около 65% от всего децентрализованного рынка бесконечных контрактов. Очевидно, что, столкнувшись с таким конкурентом, Solana не хочет оставаться позади, и поэтому выпустила эту дорожную карту ICM.

Итак, что же происходит с этим “шоу подражаний”? Может ли Solana действительно догнать или даже превзойти Hyperliquid? Сегодня мы подробно обсудим эту тему.

📋 Фон и содержание ICM

Кто ведет эту трансформацию?

Во-первых, давайте посмотрим, кто составил эту дорожную карту. Участвуют все весомые игроки экосистемы Solana:

• Фонд/Лаборатории Solana: Об этом можно не говорить, “родной папа” Solana, отвечающий за общую координацию и разработку основного протокола.
• Anza: компания-разработчик, основанная бывшими членами Solana Labs, немного похожа на ConsenSys из Ethereum. Они взяли на себя много работы по разработке ключевых технологий в этой дорожной карте, таких как новый консенсусный протокол Alpenglow.
• Jito Labs: Поставщик инфраструктуры MEV на Solana, обладающий огромным влиянием, практически контролирующий “жизнь и смерть” всего MEV-трафика на Solana. На этот раз они возглавили предоставление решений по сортировке транзакций, таких как Block Assembly Marketplace (BAM).
• Multicoin Capital: известная криптоинвестиционная компания и один из первых сторонников Solana. Обладая значительными долями SOL и проектами экосистемы, она также имеет значительное влияние в техническом направлении.
• DoubleZero: команда, сосредоточенная на ускорении сетевой связи, предоставляет специализированные оптоволоконные сетевые решения для повышения скорости связи между узлами верификации Solana.
• Drift: Ведущий проект децентрализованной биржи perpetual контрактов на Solana. Ранее Drift использовал оффлайн-матчинг, и в условиях полной работы на блокчейне Hyperliquid показал некоторые трудности; участие в разработке дорожной карты явно направлено на то, чтобы воспользоваться обновлением базового уровня для улучшения ситуации.

Основная проблема, которую нужно решить

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

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

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

Три шага ICM

Solana разделила этот грандиозный план на три этапа:

Краткосрочный (1-3 месяца): Основное внимание будет уделено оптимизации текущего опыта цепочных транзакций, улучшению удобства приложений с ордерными книгами и снижению вредного вмешательства MEV. Конкретно включает в себя:

• Модуль Block Assembly Marketplace (BAM) от Jito Labs запущен в основной сети. Значение этого модуля заключается в том, что он предоставляет временную внешнюю систему до запуска окончательного ACE (Application Controlled Execution), позволяя смарт-контрактам на Solana иметь автономные права на порядок транзакций.
• Команда Anza оптимизировала вероятность успешного “входа в одну и ту же ячейку”, тем самым снижая проскальзывание и потери MEV.

Эти улучшения ожидаются в период с июля по сентябрь 2025 года.

Среднесрочный (3-9 месяцев): Внедрение специализированной высокоскоростной сети и новой версии консенсуса, значительное снижение задержки, увеличение пропускной способности:

• Развертывание специализированной оптоволоконной сети DoubleZero для обеспечения валидаторов высокоскоростной связи с почти нулевой джиттер и снижением задержки до 100 мс.
• Запуск протокола согласия Alpenglow, который сокращает время окончательного подтверждения с примерно 12,8 секунд до примерно 0,15 секунд.
• Разработка асинхронного выполнения программ (Asynchronous Program Execution, APE), уменьшает блокировку выполнения транзакций для консенсуса.

Долгосрочные (9-30 месяцев): Революционное обновление архитектуры Solana, цель - достичь этого к 2027 году:

• Многочисленные параллельные лидеры (Multiple Concurrent Leaders, MCL): Позволяет нескольким валидаторам одновременно предлагать транзакции в своих собственных pipeline, а затем сортировать эти параллельные блоки по приоритетной комиссии. Это ослабляет монополию единого упаковывателя и повышает устойчивость к цензуре.
• Нативные приложения могут контролировать выполнение (Application Controlled Execution, функция ACE): действительно предоставляет смарт-контрактам на блокчейне власть контролировать порядок выполнения транзакций.

Анализируя ситуацию, автор считает, что история, стоящая за предложением этой дорожной карты ICM, должна быть такой: старый DEX на Solana Drift был обойден новичком Hyperliquid с отличным опытом “цепочного Binance”. Drift сам не в силах противостоять, поэтому вынужден обратиться за помощью к “про” как Solana Labs, Anza, Jito и другим. “Про” предложили такую техническую программу модернизации, как ICM, заявляя, что хотят воспроизвести все навыки Hyperliquid для Drift, чтобы помочь ему снова сразиться на рынке DEX. Однако “про” также сказали, что эта техническая модернизация крайне сложна, поэтому технический план разделен на стратегию из трех этапов, и в ближайшее время Drift сможет получить только оборудование от Jito BAM, чтобы Drift мог как-то использовать это и сравниваться с Hyperliquid.

Определив фон истории, в следующих главах автор подробно проанализирует, какие именно фишки ICM подражает и воспроизводит у Hyperliquid.

🎭 Имитация 1: Механизм сортировки сделок

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

Ультимативное решение ICM: применение контролируемого исполнения (ACE)

Дорожная карта ICM предлагает концепцию ACE (Application Controlled Execution), то есть передача права на сортировку транзакций на приложения на каждом блокчейне, позволяя приложениям самостоятельно решать, как сортировать и выполнять транзакции, связанные с этим приложением. Например, в будущем на Solana, реализующей ACE, контракты DeFi могут установить следующие настраиваемые правила сортировки транзакций:

• Обновление цен Oracle: DeFi-приложения могут перед проведением крупных сделок сначала вставить одну транзакцию, чтобы получить последнюю цену от оракула, чтобы гарантировать, что заказы будут исполняться по последней разумной цене и предотвратить арбитраж на основе устаревших цен, предлагаемых маркет-мейкерами.
• Приоритет отмены ордера: Приложение может установить, что “запрос на отмену” будет иметь приоритет перед новым “сделкой на покупку”, позволяя мейкерам иметь возможность вовремя отменить ордер в неблагоприятной ситуации на рынке.
• Аукцион на заднем плане: Например, после появления крупного ордера на покупку, который поднимает цену, DeFi-приложение выставляет на аукцион возможность «следовать за ним», и тот, кто готов вернуть наибольшую выгоду протоколу (или пользователю), получит возможность выполнить свою сделку рядом с крупным ордером. DeFi-приложение может вернуть доход от аукциона пользователям, тем самым превращая токсичный MEV-трафик в здоровый доход.

BAM JITO: переходное решение

Перед официальным запуском ACE, Jito Labs представила переходное решение под названием Block Assembly Marketplace (BAM). Рабочий процесс BAM таков:

1. Пользователь отправляет транзакцию узлу, работающему на программном обеспечении BAM (а не напрямую текущему Лидеру).
2. Узлы BAM собирают локальные транзакции и выполняют различные плагины (plugin) для переупорядочивания пакета транзакций (Bundle) с защитой конфиденциальности (плагины работают в безопасной среде TEE и скрывают содержимое транзакции до выполнения). С помощью плагинов разработчики приложений могут настраивать различные правила сортировки для своих контрактов, например, приоритет отмены заказов, обновление цен оракла перед сватовством, а также выполнение сложных конкурентных ставок внутри приложения.
3. Отсортированный Bundle транзакций отправляется Лидеру Solana для упаковки в блокчейн.

BAM можно рассматривать как полигон для экспериментов перед запуском ACE в блокчейн, его функционал очень близок к окончательному ACE, только он работает в независимой сети вне протокола основной цепи Solana.

Стоит отметить, что Jito ранее предоставлял инфраструктуру для извлечения MEV (например, Jito Block Engine), и его бизнес-модель заключалась в том, чтобы создавать возможности для арбитражников и делиться доходами за счет оптимизации сортировки транзакций. Это в определенной степени является “копьем”, стоящим на стороне обычных пользователей и противостоящим арбитражникам. Однако в начале 2024 года Jito закрыл публичный мемпул для арбитражных роботов (mempool), чтобы уменьшить негативные внешние эффекты, такие как сэндвич-атаки. Этот шаг показывает, что сообщество Solana стремится подавить вредный MEV и защитить справедливость пользователей.

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

Учиться у HYPERLIQUID

Вышеупомянутая идея ACE/BAM на самом деле может рассматриваться как попытка догнать механизм согласования на блокчейне Hyperliquid. Hyperliquid — это специализированная цепочка (Appchain), которая изначально создана для обслуживания DEX. Более того, HLP Vault, управляемый официально Hyperliquid, на самом деле является одним из крупнейших маркет-мейкеров этой платформы, поэтому несложно понять, что правила цепочки Hyperliquid больше ориентированы на поставщиков ликвидности, и уже на уровне цепочки реализовано множество дизайнов, защищающих маркет-мейкеров, таких как:

• Приоритет защиты для размещения ордеров: отмена ордеров и размещение ордеров только в качестве мейкера обрабатываются в первую очередь, чтобы избежать неблагоприятных сделок для маркет-мейкеров без их ведома. “Приоритет на отмену ордеров”, упомянутый Solana ACE, Hyperliquid уже практикует на протяжении многих лет.
• Гарантия актуальной цены: Процесс ликвидации и сватовства в Hyperliquid акцентирует внимание на использовании последних цен от оракулов и состояния маржи для проведения “двойной проверки”. Например, когда происходит исполнение ордера, система снова запрашивает последнюю цену оракула для оценки маржи обеих сторон, чтобы гарантировать, что риск не возникнет из-за задержки в цене. Это похоже на ACE, который вставляет обновление оракула перед исполнением сделки.
• Защита от самопродаж: если одна и та же адреса встречаются при покупке и продаже, Hyperliquid автоматически отменяет сделку, а не проводит ее, чтобы предотвратить манипуляции с объемом или ненужные расходы.

ACE/BAM на Solana ICM, безусловно, является попыткой “изучить опыт” Hyperliquid. Hyperliquid, будучи лидером на рынке CLOB, реализовала различные механизмы, благоприятные для маркет-мейкеров, с помощью специальной цепочки. Теперь Solana надеется использовать универсальную цепь и модульные плагины, чтобы воспроизвести этот эффект — то есть дать каждому приложению контроль над сортировкой сделок, аналогичный Hyperliquid.

⚡ Имитация два: Мгновенная окончательность

Сравнение существующих консенсусов

Solana в настоящее время использует Tower BFT, подтверждение и окончательность являются вероятностными и прогрессивными: блок считается “подтвержденным(Confirmed)”, если он получает 2/3 голосов, но необходимо накопить около 32 последующих блоков (обычно около 13 секунд), чтобы он был закреплен как “окончательно(Finalized)”. Для некоторых приложений (например, высокочастотной торговли) время окончательного подтверждения в несколько секунд все еще слишком долго.

HyperBFT — это алгоритм консенсуса, разработанный Hyperliquid. Он вдохновлен консенсусом HotStuff и использует двухраундное голосование для подтверждения блоков, достигая “мгновенной окончательности”.

• Первый раунд: предварительное голосование ( Prevote ): валидатор, получив кандидатский блок, который транслирует Пропозер, проводит быструю проверку. Если проверка пройдена, каждый валидатор голосует за этот блок одной “предварительной голосующей” ( Prevote )票 и транслирует её всей сети. Этот голос представляет собой: “Я предварительно просмотрел, с этим блоком все в порядке.”
• Второй раунд: Предварительная подача (Precommit): Как только какой-либо валидатор соберет более двух третей голосов от других валидаторов за один и тот же кандидатный блок Prevote, он получает достаточно уверенности в том, что большинство членов сети одобряют этот блок. Таким образом, этот валидатор выдаст более весомый “предварительный коммит” (Precommit) голос, и распространит его. Этот голос означает: “Я увидел, что большинство сети согласны, я готов официально записать этот блок в реестр.”
• Когда валидатор соберет Precommit от более чем двух третей валидаторов по одному и тому же кандидату на блок, консенсус будет достигнут! Этот блок считается окончательно подтвержденным(Finalized). Он будет навсегда и необратимо добавлен в блокчейн.

Это означает, что каждый блок Hyperliquid является окончательным блоком, нет возможности отката ветвления, задержка создания блоков в цепи крайне низка — официально раскрытая средняя задержка подтверждения составляет около 0,2 секунды, в 99% случаев не превышает 0,9 секунды. Эта миллисекундная окончательная определенность очень идеальна для высокочастотной торговли, поскольку как только сделка отправлена, она быстро подтверждается и не может быть переработана, что значительно повышает эффективность капитала.

ALPENGLOW обеспечивает мгновенную окончательность

Alpenglow — это новый консенсусный протокол, который Solana готовит к запуску, цель которого — ускорить окончательное подтверждение блоков до 1-2 слотов (примерно 150 мс), чтобы добиться мгновенной окончательности, аналогичной HyperBFT. Компонент, заменяющий TowerBFT и отвечающий за консенсус в Alpenglow, называется Votor. Это система двойного голосования:

• Быстрый проход: если в первом раунде голосования за блок более или ровно 80% сетевых “прав” (можно понимать как вес голосования, представленный количеством SOL токенов, заложенных валидаторами) проголосует за то, что этот блок действителен, то этот блок будет немедленно подтвержден “финальной” (Finalize).
• Медленный канал: Если в первом раунде голосования доля согласных прав не достигнет 80%, но составит 60% или более, Votor запустит второй раунд голосования. Если после окончания второго раунда голосования доля согласных прав на этот блок останется на уровне 60% или выше, этот блок также будет окончательно подтвержден.

Votor говорит: “Мы предполагаем, что одна раунда голосования достаточно для подтверждения, но если условия не идеальны, мы запускаем процесс голосования в два раунда, который почти идентичен HyperBFT, в качестве страховки.” Это на самом деле имитация механизма голосования Hyperliquid.

Цена и меры по обеспечению мгновенной окончательности

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

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

• В Alpenglow есть еще один компонент Rotor, который заменяет устаревший протокол распределения данных Turbine. В отличие от Turbine, который требует многоуровневых промежуточных передач, Rotor использует режим “однопроходной ретрансляции”, позволяя блокам данных быстрее достигать целевых валидаторов, значительно снижая задержку передачи. Кроме того, в существующей механике Turbine положение узлов в дереве распределения данных в основном определяется порядком по весу stake: узлы с большим количеством stake располагаются на более высоких уровнях и первыми получают фрагменты данных (shreds), но при этом им также приходится выполнять больше задач по последующей ретрансляции, что требует больших затрат на пропускную способность. Предполагается, что узлы с большим количеством stake часто являются “богатыми людьми”, и, следовательно, имеют более мощное оборудование и более достаточные ресурсы пропускной способности. Rotor обновляет эту логику, больше не полагаясь исключительно на размер stake, а учитывая фактическую пропускную способность и производительность связи каждого узла. Узлы, которые демонстрируют лучшие результаты в реальной сети, будут динамически расположены в ключевых позициях, тем самым обеспечивая оптимальный путь распространения данных для всей сети и обеспечивая быструю и стабильную “экспресс”-услугу.
• Сеть DoubleZero основана на специализированной оптоволоконной сети и технологии мультикастинга, предоставляя низколатентную связь, в десять раз быстрее, чем общественный интернет. Это снижает задержку и дрожание сообщений между географически разнесенными узлами, делая физическую основу для быстрого консенсуса более надежной.

Тем не менее, для Solana по-прежнему крайне сложно добиться “высокой децентрализации + миллисекундной окончательности”. Именно поэтому Alpenglow ожидает, что потребуется еще более года разработки, и запуск запланирован на начало 2026 года (только можно надеяться на это).

🔄 Имитация три: Асинхронное выполнение конвейера

Асинхронный конвейер HYPERLIQUID

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

А Hyperliquid, наоборот, вводит многопоточность, декомпозируя рабочий процесс на две параллельные линии: “Сортировка (консенсус)” и “Исполнение”. Процесс исполнения следующий:

1. Временная точка T1:

   • Консенсусный конвейер: валидаторы приходят к согласию по содержанию и порядку транзакций блока N-1.

2. Время T2 (место, где начинается магия) :

   • Консенсусный конвейер: Начинает обработку блока N. Он упаковывает и сортирует транзакции в сети, а затем голосует и достигает консенсуса по этому порядку. Ему совершенно не важно, каковы результаты выполнения блока N-1.
   • Исполнение пайплайна: Получив блок N-1, достигший консенсуса в момент T1, начинаем исполнять содержащиеся в нем транзакции.

3. Временная точка T3 (потоковое выполнение):

   • Консенсусный пайплайн: Завершил консенсус по блоку N и передал результаты консенсуса (упорядоченный список транзакций) в исполнительный пайплайн. Затем он, не теряя времени, начинает обрабатывать блок N+1.
   • Исполнение конвейера: Завершено исполнение блока N-1 и в конечном итоге подтверждено состояние. Затем он бесшовно соединяется, мгновенно получает только что завершенный блок N от конвейера консенсуса и начинает исполнять его транзакции.

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

APE план ICM

выполнение

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

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

Однако, поскольку Solana является универсальной цепочкой, зависимости в транзакциях гораздо сложнее, чем в системе order book. Поэтому, чтобы воспроизвести производительность Hyperliquid в универсальной среде, Solana сталкивается с гораздо более серьезными инженерными задачами, требующими переработки множества кодов, что невозможно реализовать в краткосрочной перспективе. Таким образом, в дорожной карте ICM это также можно отнести к среднесрочному планированию. Тем не менее, для реального запуска APE необходимо преодолеть ряд трудностей:

• Экстремальная сложность кода: Чтобы распределенная система поддерживала асинхронное параллельное выполнение, требуется множество изменений на низком уровне. Как только вводится многопоточность, сложность программного обеспечения клиента валидационного узла Solana возрастет в геометрической прогрессии, и риск неизвестных ошибок также возрастет. Неправильная обработка условия гонки может привести к ошибкам в консенсусе, и последствия будут катастрофическими.
• Повышение аппаратных требований: Параллельное выполнение требует мощного многоядерного процессора и больше памяти, чтобы одновременно запускать несколько потоков выполнения, поддерживать несколько временных состояний и точек отката. Уровень входа для узлов Solana изначально достаточно высок, и если его дополнительно повысить, это повлияет на децентрализацию сети.
• Обработка худшего случая: Худший случай параллельного выполнения возникает, когда большое количество транзакций борется за одно и то же состояние. Например, когда некоторые популярные контракты (такие как популярные DEX или контракты на закупку) вызывают чтение и запись всех транзакций в один и тот же аккаунт, параллельный планировщик будет постоянно проверять конфликты, откатывать и воспроизводить, что может оказаться медленнее, чем последовательное выполнение. Как элегантно снизить производительность в худшем случае, не допуская зависания системы или резкого падения производительности, является сложной задачей проектирования архитектуры.
• Сложность разработки и аудита: Проверка безопасности в асинхронной и многопоточной среде очень сложна. Сообществу Solana необходимо выделить дополнительные ресурсы для аудита новой модели исполнения, чтобы предотвратить злонамеренное использование уязвимостей консенсуса, возникающих из-за параллелизма.

🤔 Удастся ли этот имитационный шоу?

В свете вышеизложенного, дорожная карта Solana ICM на самом деле представляет собой глубокое “подражание” технологии Hyperliquid. Основная команда Solana планирует воспроизвести все лучшие навыки Hyperliquid и передать их Drift, чтобы помочь ему снова вступить в бой на рынке DEX с Hyperliquid. Однако, автор не оптимистично настроен относительно перспектив этого подражания.

Уровень сложности технологии резко возрос

Успех Hyperliquid во многом основан на его благоприятных врожденных условиях:

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

Что касается Solana, для достижения уровня Hyperliquid при сохранении универсальности публичной цепочки и степени децентрализации, техническая сложность возрастает экспоненциально. Например, консенсус HyperBFT от Hyperliquid может обеспечить задержку в 0.2 секунды с менее чем 5 узлами, в то время как Solana, чтобы 2000 узлов достигли такой же задержки, должна преодолеть пределы сетевой связи; механизм сводки Hyperliquid обслуживает только логику своей биржи, тогда как ACE/BAM Solana должен адаптироваться к множеству разнообразных DeFi-протоколов.

Можно сказать, что Solana изучает курс Hyperliquid, и уровень сложности этого курса выше, чем тот, с которым сталкивался Hyperliquid, “неизвестно на каком уровне”. Дорожная карта ICM разбивает эти задачи до 2027 года, что показывает, что официальные лица также понимают, что это не дело одного дня.

Противоречие между децентрализацией и эффективностью

Еще одно отличие Solana от Hyperliquid заключается в темпе управления и обновления. Команда Hyperliquid небольшая, решения сосредоточены, нет внешнего контроля со стороны управления, поэтому действия происходят очень быстро. В марте этого года, когда Hyperliquid столкнулся с манипуляцией контрактом JELLY, команда мгновенно приняла решение и за несколько часов сняла соответствующий рынок, обеспечив безопасность средств, что в полной мере продемонстрировало, что централизованное принятие решений, хотя и “политически некорректно”, действительно эффективно и полезно в критические моменты.

Однако Solana как общественная цепочка имеет фонд,核心开发, и сообщество, что приводит к многим противоречиям, и процесс обновления относительно медленный и консервативный. Например, ожидаемый Firedancer (высокопроизводительный клиент Solana от Jump) с момента запуска в 2022 году до сих пор (середина 2025 года) находится на стадии тестирования и доработки, и еще не полностью запущен; любые изменения, связанные с консенсусом, требуют длительного аудита и работы тестовой сети. Что касается изменений в дорожной карте ICM, они еще более значительны: необходимо заменить основной алгоритм консенсуса, ввести новое параллельное выполнение и децентрализовать ключевую власть, что сопряжено с высокими трудностями и рисками. Можно ожидать, что в течение следующих двух-трех лет команда Solana должна постепенно продвигать эти обновления, и на каждом этапе могут возникнуть неожиданные технические проблемы или сопротивление со стороны сообщества.

Например, чтобы пользователи действительно выиграли от BAM, который был выпущен Jito, большинство валидаторов должны переключиться на клиент, поддерживающий BAM. В противном случае, если транзакции пользователей иногда проходят через BAM, а иногда нет, это приведет к непоследовательному опыту и даже к арбитражным уязвимостям. Проблема в том, что Solana не может заставить валидаторные узлы обновить клиент. Поэтому, даже если BAM будет успешно разработан, скорость его продвижения также трудно предсказать. Таким образом, график в ICM является лишь оптимистичным планом, и его реализация может затянуться, а для достижения всех целей может потребоваться ждать долго.

Даже если все пройдет гладко, к 2027 году Solana реализует такие функции, как ACE, это будет всего лишь “успешная компенсация” — чтобы догнать функции, которые Hyperliquid уже предоставила в 2023-2024 годах. А Hyperliquid сама не остановится: например, предложение HIP-3 будет запущено во второй половине 2025 года, позволяя сообществу самостоятельно выставлять на рынок бессрочные контракты. Различные инновации еще больше расширят охват рынка Hyperliquid. Когда Solana наконец-то реализует текущие функции Hyperliquid, возможно, Hyperliquid уже откроет новые преимущества для лидерства.

Превосходя технологическую конкуренцию

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

• Например, в токеномике Hyperliquid нет венчурного финансирования, более 76% токенов распределены среди сообщества. Прибыль от сборов платформы может быть использована для выкупа токенов HYPE, что действительно обеспечивает совместное использование интересов с пользователями, без проблемы чрезмерной эксплуатации пользователей со стороны капитальных инвесторов. Это принесло Hyperliquid много преданных пользователей.
• Кроме того, команда Hyperliquid крайне чутко реагирует на рыночный спрос: когда NFT были на пике популярности, они запустили индекс NFT; когда SocialFi стал актуален, был представлен индекс FriendTech; HIP-2 решил проблему “холодного старта новых токенов и нехватки начальной ликвидности”; Hyperps справился с задачей предоставления фьючерсной торговли для активов, которые еще не вышли на рынок; запланированное на этот год обновление HIP-3 поддерживает возможность для любых проектов самостоятельно выпускать рынок бессрочных контрактов. Инновации в продукции появляются одно за другим, а разнообразные торговые категории и новые способы торговли значительно увеличивают привлекательность Hyperliquid как торговой платформы — пользователи приходят сюда не только за скоростью, но и за возможностями заработка, которых нет нигде больше.

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

Таким образом, если просто следовать за Hyperliquid, то всегда придется оставаться в тени. Настоящая возможность дорожной карты Solana ICM не в области бессрочных контрактов или ордерных книг. В экосистеме Solana есть множество областей, в которые Hyperliquid еще не вошел, такие как MEME-лаунчпады, кредитные протоколы и т.д., и эти области также могут использовать улучшения, принесенные ICM, для создания более плавного пользовательского опыта. Если Solana сможет инновационно развивать функции в этих областях и решать проблемы пользователей, то даже если в рынке бессрочных контрактов не удастся сразу добиться успеха, это все равно сможет укрепить реализацию их видения “интернет-капиталов”. В конце концов, Hyperliquid, как бы он ни был силен, все же является приложением в узкой области, в то время как Solana имеет обширную и разнообразную карту приложений, что является ее крупнейшим капиталом на долгосрочную перспективу.

🏁 Заключение: легко подражать, трудно превосходить

Дорожная карта Solana ICM подчеркивает решимость сообщества Solana не сдаваться и настойчиво догонять. От ACE до Alpenglow и до APE, каждая из них соответствует уникальным функциям Hyperliquid, действительно имеет смысл “целенаправленного подражания”.

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

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

Дорожная карта ICM描绘未来令人憧憬, но сможет ли она осуществить “обгон на повороте”, покажет время. Как обычные пользователи, мы можем ожидать, что эта конкуренция принесет лучший опыт цепочечных транзакций — независимо от того, кто в конечном итоге победит, пользователи будут в выигрыше.

Данный текст основан на открытой информации и не является инвестиционной рекомендацией. Инвестиции в криптовалюту сопряжены с высоким риском, пожалуйста, принимайте взвешенные решения, DYOR.

Если вам понравилась эта статья, пожалуйста, подписывайтесь, ставьте лайки и делитесь поддержкой!