1. Может ли Соглашение исправить блокчейны?

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

Каждый блокчейн стремится достичь баланса в отношении троицы блокчейна: балансировка скорости, безопасности и децентрализации. Проекты часто могут ставить приоритет лишь на две функции за счёт третьей.

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

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

Доказательство работы (PoW): Майнеры решают сложные головоломки с помощью вычислительной мощности, чтобы добавлять блоки, и получают вознаграждение криптовалютой. Это безопасно, но требует больших затрат энергии и медленно (например, Bitcoin, Ethereum до 2022 года).

Proof of Stake (PoS): Валидаторы ставят криптовалюту на шанс создать блоки. Этот метод энергосберегающий и быстрый, но может быть выгоден богатым участникам (например, после 2022 года Ethereum, Cardano).

Делегированный доказательство долевого участия (DPoS): Владельцы токенов голосуют за делегатов для подтверждения транзакций, обеспечивая скорость и масштабируемость, но рискуя централизацией (например, EOS, Tron).

Доказательство авторитетности (PoA): Доверенные узлы подтверждают на основе личности, что делает его быстрым и эффективным, но менее децентрализованным (например, VeChain).

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

Биткоин в среднем обрабатывает 7 транзакций в секунду (TPS).

Ethereum после PoS достигает 15–30 TPS.

Visa, напротив, в среднем обрабатывает 1 700 TPS ежедневно.

Эти разрывы вызывают задержки, заторы и высокие комиссии, выявляя проблемы масштабируемости.

1.2 Новые модели соглашений

Возникающие уровни-1 (L1) вроде @Hyperliquidx, @Monad_xyz, и @Soniclabsведут к новым механизмам консенсуса, специально разработанным для решения этих вызовов, повышая скорость, масштабируемость и влияние, способствуя доверию.

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

2 Hyperliquid

Hyperliquid - это блокчейн L1, построенный для децентрализованной торговли высокоскоростной и низкой стоимости. Он разделяется на два столпа:

HyperCore: двигатель на цепи для постоянных фьючерсов и ордеров на срочную поставку с окончательностью в один блок.

HyperEVM: платформа смарт-контрактов, совместимая с Ethereum.

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

HyperCore может обрабатывать до 200 000 ордеров в секунду, теоретический пик, который будет увеличиваться с обновлениями программного обеспечения узла.

HyperEVM представляет собой платформу смарт-контрактов Ethereum для Hyperliquid, предлагая ликвидность и финансовые инструменты HyperCore в качестве открытых ресурсов.

С помощью HyperCore и HyperEVM команда стремится обеспечить беспрепятственное взаимодействие между децентрализованными приложениями (dApps) и компонентами блокчейна без ущерба для эффективности или пользовательского опыта.

2.1 Механизм соглашения

Изначально Hyperliquid использовал алгоритм консенсуса Tendermint. Однако для лучшей поддержки высокочастотной торговли и достижения более высокой пропускной способности транзакций потребовалось более продвинутое решение.

Для решения этой проблемы Hyperliquid разработала механизм согласования под названием HyperBFT. Эта гибридная система объединяет PoS с Byzantine Fault Tolerance (BFT) и оптимизирована для высокой пропускной способности, низкой задержки и надежной безопасности.

Модель PoS основана на протоколе HotStuff, где валидаторы генерируют блоки, заложив $HYPEТокены. Гибридный подход HyperBFT более энергоэффективен, чем традиционные методы PoW, при этом обеспечивая надежную безопасность.

2.2 Масштабируемость и Скорость

HyperBFT достигает медианной окончательности в 0.2 секунды и задержки менее 0.9 секунды. Ордербук on-chain имитирует точность централизованной биржи, поддерживая плечо 50x, торговлю одним кликом и стоп-лимиты.

Hyperliquid превосходит в сценариях высокой пропускной способности, обрабатывая 200 000 TPS одновременно без шардирования. В настоящее время это в основном ограничивается сетевой задержкой и распределением валидаторов.

2.3 Challenges

Небольшое количество валидаторов (безопасность): Hyperliquid относительно централизован, с всего 16 валидаторами по сравнению с огромной сетью Ethereum из 800 тыс. валидаторов. Они стремятся расширить свой набор валидаторов по мере роста сети, соответствуя своей цели децентрализации.

Непроверенная устойчивость к крупным кибератакам вызывает вопросы о ее долгосрочной децентрализации и надежности. Эта централизация представляет собой угрозу безопасности, особенно в отношении $2.3 миллиарда $USDCв мосту, целью которого стал попытка взлома в 2024 году.

Влияние централизации: В марте 2025 года Hyperliquid столкнулся с инцидентом с$JELLYтокен. Трейдер манипулировал системой ликвидации платформы, создавая три учетные записи и принимая маржинальные позиции: две длинные на сумму 4,05 миллиона долларов и одну короткую на 4,1 миллиона$JELLYфьючерсы. Это привело к 400% взрывному росту цен и самоликвидации трейдера, что привело к тому, что казначейство Hyperliquid приняло короткую позицию на $6 миллионов. Это привело к нереализованным убыткам для поставщиков ликвидности, оцениваемым в диапазоне от $700 000 до $10 миллионов. Однако после вмешательства Hyperliquid казначейство заработало $700 000 прибыли, так как Hyperliquid в конечном итоге снял с листинга $JELLYконтракт, вызывающий дебаты о децентрализации и прозрачности управления.

Риски торговли с высоким плечом: 13 марта 2025 года кит ликвидировал$ETHОткрытие длинных позиций через высокотехнологичную торговлю с использованием высокого плеча привело к потере приблизительно 4 миллионов долларов в хранилище HLP. Такие события подчеркивают уязвимость платформы к рыночной манипуляции и необходимость надежных стратегий управления рисками.

Конкуренция: Закрытый исходный код Hyperliquid и отсутствие автоматических штрафов для валидаторов ограничивают прозрачность и устойчивость. Конкуренция со стороны высокопроизводительных платформ, таких как Solana, новых уровней L1, таких как Monad и MegaETH, а также продвинутых DEX, таких как dYdX, представляет собой вызовы.

Масштабируемость: Hyperliquid спроектирован для масштабируемости, обрабатывая до 200 000 TPS с окончательностью менее секунды. Однако экстремальные условия, такие как массовые маржинальные сделки, могут привести к вызовам, таким как напряженность ликвидности или задержки координации валидатора.

3. Monad

Monad - это совместимая с EVM L1 для масштабируемости и производительности, использующая параллельное выполнение и MonadBFT.

Monad нацеливается на до 10 тыс. транзакций в секунду с блоками, создаваемыми каждые 500 мс и финализируемыми за одну секунду. Он способствует децентрализации, решая проблемы Эфириума (например, медленные скорости, высокие комиссии и ограниченная масштабируемость). Его тестовая сеть была запущена 19 февраля 2025 года, с предположениями о запуске основной сети в III-IV квартале 2025 года.

3.1 Механизм соглашения

Архитектура Monad сосредоточена на его собственном механизме консенсуса MonadBFT, оптимизированном развитии протокола HotStuff BFT .

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

MonadBFT: Этот алгоритм преобразует трехфазный процесс HotStuff в двухфазный, улучшая скорость валидатора. Валидаторы поочередно выступают в качестве лидеров: один предлагает блок и собирает предыдущие голоса в кворум-сертификат (QC), доказательство согласия для подтверждения предыдущего блока. Механизм тайм-аута делает сеть надежной в случае отказа лидера, обеспечивая безопасность в частично синхронных условиях.

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

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

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

Диаграмма ниже иллюстрирует процесс конвейерной обработки MonadBFT, показывая, как валидаторы (Алиса, Боб, Чарли, Дэвид и др.) предлагают, голосуют и завершают блоки (N, N+1, N+2 и т. д.) через перекрывающиеся раунды.

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

3.2 Масштабируемость и скорость

Monad объединяет эффективность MonadBFT с параллельным выполнением, что позволяет ему превзойти традиционные L1 за счет одновременной обработки транзакций, избегая шардирования и обеспечивая быструю окончательность. Его теоретическая пропускная способность может быть выше упомянутой выше (10 тыс. TPS, окончательность менее секунды), однако реальные результаты зависят от сетевой задержки и распределения валидаторов.

3.3 Проблемы

Сложность выполнения: Оптимистическое параллельное выполнение Monad может привести к несоответствиям, откатам или уязвимостям (например, эксплуатации граничных случаев). Его передовые функции (MonadBFT и параллельное выполнение) добавляют сложности, увеличивая затраты на разработку и обслуживание, особенно для меньших команд. Это может затруднить рост и безопасность, став вызовом для меньших команд и делая его предпочтительным для команд с более крупными ресурсами и опытом разработки.

Задержка сети: Показатели TPS и окончательность в реальном мире зависят от распределения валидаторов и задержки, что может привести к недостаточной производительности.

Непроверенный масштаб: Перед основной сетью утверждение Monad о 10 000 TPS остается недоказанным, с возможными ошибками или узкими местами.

Конкуренция: Платформы высокой пропускной способности, такие как Sonic, Arbitrum и Solana, могут стать вызовом для принятия разработчиками и пользователями.

Кривая обучения: Несмотря на совместимость с EVM, уникальные системы Monad (MonadBFT, MonadDB) могут замедлить принятие разработчиком.

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

4. Соник

Sonic - это совместимая с EVM L1 для высокой пропускной способности и финальности транзакций менее чем за секунду, развивающаяся из экосистемы Fantom Opera.

Sonic внедряет заметные операционные улучшения: его последний протокол согласования, SonicCS 2.0, достигает увеличения скорости согласования в 2 раза и снижения использования памяти на 68% за эпоху (с 420 МБ до 135 МБ), снижая требования к ресурсам для валидаторов и улучшая масштабируемость.

Эти обновления решают несколько проблем блокчейна:

Медленная обработка транзакций

Высокие операционные расходы

Фрагментированные экосистемы

С переименованной идентичностью Sonic поощряет разработчиков путем перераспределения до 90% сборов за транзакции в сети через свою программу монетизации сборов (FeeM), способствуя созданию и принятию dApp.

4.1 Механизм соглашения

Соглашение Лахесиса Sonic объединяет направленные ациклические графы (DAG) с асинхронной Византийской устойчивостью к ошибкам (ABFT), продвигаясь за пределы основ Фантом Опера.

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

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

PoS: Валидаторы ставят минимум 500k$Sтокены для участия в пакетной обработке транзакций в блоках событий в рамках локальных DAG. Соглашение достигается, когда достаточное количество валидаторов подтверждают эти блоки как «корни» на основной цепи, обеспечивая окончательность в течение субсекунд. Эта система PoS балансирует скорость, безопасность и децентрализацию, при этом ставки токенов сдерживают недобросовестное поведение.

На рисунке ниже показан DAG для определенного узла:

События оранжевого цвета представляют события кандидатов-лидеров

Желтые события указывают на события, совершенные лидером.

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

4.2 SonicCS 2.0 - их последнее обновление механизма согласования

Sonic недавно обновил свой механизм консенсуса до SonicCS 2.0, представленного 27 марта 2025 года. Этот протокол использует подход на основе DAG с перекрывающимися выборами, сокращая вычислительные затраты и использование памяти на 68%. Эксперименты с 200 эпохами данных основной сети Sonic показывают средний ускорение в 2,04 раза (варьируется от 1,37 до 2,62 раза) и значительную эффективность использования памяти, укрепляя способность Sonic обрабатывать более 10 тыс. TPS с окончательностью менее секунды. SonicCS 2.0 скоро появится на основной сети, с предстоящим подробным техническим отчетом.

4.3 Масштабируемость и скорость

Гибридное соглашение Лахесиса Sonic объединяет адаптивность DAG с целостностью ABFT, обеспечивая быструю, безопасную окончательность транзакций без необходимости шардирования. Этот дизайн поддерживает безпрепятственное масштабирование по мере роста спроса на сеть.

SonicCS 2.0 может потенциально улучшить производительность главной сети Sonic, приблизив ее к теоретическим оценкам 396,825 TPs. Однако важно отметить, что практические результаты зависят от сетевой задержки и распределения валидаторов. По словам @AndreCronjetechмаксимальная измеренная в реальном времени TPS на Sonic уже составляла около 5 140, что довольно впечатляюще.

Sonic полностью совместим с EVM, оптимизируя производительность в этой рамке, а не заменяя ее отдельной виртуальной машиной. Векторизованные операции SonicCS 2.0 и перекрывающиеся выборы повышают эффективность валидаторов и производительность dApp.

Источник: Chainspect

4.4 Трудности

Сложность консенсуса: При высокой нагрузке механизм консенсуса Sonic может вводить запутанные зависимости или задержки валидации, что создает риск неэффективности или эксплуатации.

Адаптация разработчика: Хотя совместимый с EMV, передовые функции Sonic (например, векторизованное голосование SonicCS 2.0) могут потребовать от разработчиков корректировки рабочих процессов, что потенциально замедлит принятие.

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

Непроверенный масштаб: Перед выпуском основной сети Pre-SonicCS 2.0 утверждение о 10k TPS не имеет полной проверки в реальном мире, и возможные узкие места или ошибки пока не проявились.

Доминирование L2: L2-решения Ethereum (например, Optimism, zkSync) предлагают схожую производительность по более низкой стоимости, используя обширную ликвидность и экосистемы разработчиков. Мост Sonic Gateway Sonic способствует межоперабельности, но конкуренция в качестве независимого L1 остается сложной.

Централизация: 500 000 $Sтребование по стейкингу и раннее управление Sonic Foundation могут привести к централизации власти, потенциально отталкивая пользователей, ориентированных на децентрализацию, и ослабляя безопасность в случае, если распределение токенов благоприятствует внутренним участникам.

5. Таблица сравнения

6. Использование экосистемы Ethereum

Hyperliquid, Monad и Sonic все используют совместимость с EVM, что позволяет разработчикам развертывать dApps на высокоскоростной инфраструктуре, используя привычные инструменты и смарт-контракты. Это обеспечивает недорогие, высокопроизводительные транзакции с надежной защитой, взаимодействуя с экосистемой Ethereum без переписывания кода.

Обеспечение разнообразных dApps

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

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

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

Monad улучшает это с 10 000 TYPS, блоками по 1 секунде и окончательностью в один слот.

За пределами Web3: потенциал предприятия

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

7. L2 as ответ Ethereum на проблему масштабирования

А что насчет L2s?

Зачем нам вообще нужны новые блокчейны L1 с изысканными механизмами согласования?

L2-решения, такие как Arbitrum, Optimism и Base, увеличили масштабируемость L1 путем обработки транзакций вне цепи. Arbitrum достигает до 4 000 TPS, в то время как Base нацеливает на тысячи с Flashblocks длительностью 0,2 секунды к середине 2025 года.

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

Новые блокчейны L1, такие как Hyperliquid, Monad и Sonic, решают эти ограничения с помощью передовых механизмов согласования. В отличие от L2, эти L1 обладают высокой производительностью без использования инфраструктуры Ethereum, избегая сложностей, таких как доказательства мошенничества или узкие места во времени блока L1.

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

Необходимость развития новых блокчейнов L1 на фоне существующих решений L2 - это актуальная тема обсуждения в Twitter:

L2s облегчают перегруженность L1, но связывают свою масштабируемость с ограничениями Ethereum. Они работают также быстро, как Ethereum, но это не учитывает тот факт, что окончательность всех транзакций L2 зависит от времени подтверждения блоков L1.

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

Взаимодействие между решениями L1 и L2 вызывает критические вопросы о будущей архитектуре блокчейн сетей.

Могут ли проблемы масштабируемости блокчейнов уровня L1 быть эффективно решены через разработку новых механизмов согласия, или необходимо интегрировать решения уровня L2 несмотря на их внутренние компромиссы?

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

Заключение и пища для размышлений

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

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

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

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

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

В заключение, новые L1, такие как Hyperliquid, Monad и Sonic, решают зависимости L2, но сталкиваются с вызовами, как видно в маленьком пуле валидаторов Hyperliquid, где всего четыре узла увеличили риски коллузии, обнаруживая уязвимости. Расширение валидаторов, обеспечение безопасности мостов и внедрение более высоких порогов утверждения, мониторинг в реальном времени и выявление аномалий могут укрепить устойчивость. Балансирование безопасности, масштабируемости и децентрализации через проактивное управление рисками является ключом к укреплению доверия и поддержанию роста DeFi, призывая пользователей тщательно изучать защитные меры платформы и разработчиков давать приоритет устойчивым защитным механизмам.

Пусть "разработчики что-то сделают": позвольте им взять на себя тяжелую техническую нагрузку и определить компромисс механизмов согласия, способствуя поиску равновесия.

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

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

Будет интересно посмотреть, как они развиваются и как переплетаются, когда начнут работать Monad (и другие конкуренты).

Отказ от ответственности:

1. Эта статья взята из [ Замковые лаборатории]. Все авторские права принадлежат оригинальному автору [@cryptorinweb3]. Если есть возражения против этого повторного издания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно мнением автора и не являются инвестиционной консультацией.
3. Команда Gate Learn выполняет переводы статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.