Monad (MON): высокопроизводительный L1 с параллельным EVM и финализацией ~0,8 с

Monad — это высокопроизводительный Layer-1 блокчейн, совместимый с EVM на уровне байткода и спроектированный для параллельного исполнения транзакций без отказа от децентрализации. Цель проекта — убрать ложный выбор между скоростью и устойчивостью сети: блок — каждые ~400 мс, а финализация достигается ориентировочно через два шага (~0,8 с). Архитектурные нововведения включают консенсус MonadBFT, протокол распространения блоков RaptorCast, асинхронный конвейер «консенсус ↔ исполнение», оптимистическое параллельное исполнение EVM, JIT-компиляцию горячих контрактов и специализированную базу состояния MonadDb.

Статус запуска. Публичный mainnet объявлен к запуску 24.11.2025 в 17:00 МСК вместе с нативным токеном MON. MON используется для оплаты газа, стейкинга и экономического выравнивания валидаторов, разработчиков и пользователей.

Для практики работы с DEX/DeFi и рыночной микроструктурой см. также: DEX, Книга ордеров, Ликвидность.

Monad (MON): ключевые свойства сети

Как Monad достигает производительности

Монолитная архитектура «L1 без роллапа» традиционно упиралась в скорость одного потока исполнения. Monad решает это комплексом взаимосвязанных оптимизаций.

1) Асинхронный конвейер (pipelining). Консенсус и исполнение выделены в независимые, но согласованные стадии. Лидер формирует блок, сеть голосует, а вычислители спекулятивно исполняют содержимое до «жёсткой» финализации. Это увеличивает бюджет времени для выполнения кода без увеличения латентности для пользователя.

2) Оптимистическое параллельное исполнение (optimistic parallel execution). Все транзакции блока изначально исполняются параллельно с фиксацией входов (прочитанных storage-слотов) и выходов (изменённых слотов). Далее — серийный коммит: результаты накатываются в исходном порядке, и если выясняется конфликт по входам (например, баланс уже изменён предыдущей транзакцией), соответствующая транзакция доисполняется повторно уже на актуальном состоянии. В итоге семантика совпадает с классическим сериализованным EVM, а пропускная способность растёт за счёт параллели и кэш-локальности.

3) MonadDb и «быстрый state-access». Главный узкий горлышко EVM — чтения/записи состояния. MonadDb хранит Меркле-три нативно (без промежуточных B-деревьев SQL/ключ-значение), экономит IOPS и позволяет вытягивать много слотов асинхронно. Параллельное исполнение подготавливает набор нужных слотов заранее («прогревает» кэш), а БД отдаёт их без лишних обращений к SSD — синергия, снижающая латентность как при первичном, так и при повторном исполнении.

4) JIT-компиляция «горячих» путей. Помимо оптимизированного интерпретатора, клиент компилирует часто вызываемые контракты в нативный код. Стоимость компиляции окупается при множественных вызовах, обеспечивая выигрыш в численных сценариях (AMM, перпеты, ордера, игры).

5) RaptorCast и сетевой слой. Быстрая доставка кусков блока по пир-сети уменьшает «дырчатость» у валидаторов, позволяет держать низкий блок-тайм и стабильнее укладываться в дедлайны голосования/репликации.

6) Консенсус MonadBFT. Переработанный BFT упор делает на устойчивость к хвостовым форкам и минимизацию оверхеда в горячем пути — важно при 400-мс блоках и плотных окнах финализации.

Совместимость с Ethereum

• Bytecode-совместимость: контракты, собранные под Ethereum, можно повторно задеплоить без перекомпиляции.
• RPC-совместимость: поддерживаются привычные JSON-RPC методы (как в geth), WebSocket и стандартные инструменты разработчика.
• Актуальные EVM-расширения: поддерживаются новые опкоды/возможности последних форков (включая Cancun), а лимит размера контракта повышен до 128 КБ — удобно для «толстых» приложений.

Для разработчиков это означает быстрый «лифтовый» перенос инфраструктуры (оракулы, индексаторы, провайдеры RPC), а для пользователей — привычные кошельки и UX.

Экономика и токен MON

• Роль токена. MON — нативный актив сети: газ, стейкинг (безопасность и участие валидаторов), базовый актив для комиссий/экономики.
• Первичное распределение. На момент запуска mainnet объявлен начальный выпуск 100 млрд MON. До 7,5% от initial supply выделено на публичную продажу перед запуском.
• Публичная продажа (Coinbase token sales). Окно покупки — 17.11.2025 17:00 МСК → 23.11.2025 07:00 МСК (минимальная заявка — эквивалент 100, цена — 0,025 за MON, верхние лимиты — по условиям платформы).
• Листинги/дистрибуция. Дистрибуция участникам публичной продажи синхронизируется с запуском mainnet. Дальнейшие листинги и программы — по анонсам экосистемы.

Важно (РФ-комплаенс): материал носит информационный характер и не является инвестрекомендацией; криптовалюты не являются средством платежа в РФ. 24k.ru не размещает «призывы к покупке», а фиксирует технические параметры и устройство сети.

Параметры сети и узлов

Сетевые параметры (по публичной документации проекта):

• блок — ~400 мс;
• финализация — ~0,8 с (N финализируется на N+2);
• ориентир пропускной способности — ~10 000 tps;
• лимит газа в тестовой сети — ориентировочно 150 млн gas/блок (будет повышаться по мере стабилизации клиентов).

Рекомендации по оборудованию для валидатора: 16 ядер @≈4,5 ГГц, 32 ГБ ОЗУ, 2×2 ТБ NVMe SSD, ≥300 Мбит/с (для full-node достаточно ~100 Мбит/с). Фокус проекта — «ускорять софтом», а не требовать «ферм из дата-центров».

Модель комиссий и UX в Monad

В классическом EVM пользователь платит gas_used × gas_price; возвраты газа учитываются постфактум. В Monad из-за асинхронного конвейера лидеры собирают блоки без знания окончательного результата исполнения, поэтому протокол списывает gas по заявленному лимиту (gas_limit). Это исключает возможность «переупаковки» транзакций под уже известную фактическую цену исполнения и упрощает инварианты безопасности. Практически это означает:

* симуляция и выбор корректного gas_limit критичны — ориентируйтесь на рекомендованные значения RPC; * вероятность непредвиденных отказов снижается за счёт резервного баланса для газа (протокол резервирует небольшой буфер, чтобы транзакции не «голодали» по газу в ближайшие несколько блоков); * дробление сложных вызовов и аккуратные лимиты — лучшая практика для DeFi.

Для каких приложений Monad особенно уместен

• Профессиональная торговля и HFT-сценарии. Низкая латентность блока и быстрая финализация улучшают UX бирж с ончейн-ордербуками и перпетуалами. Подробности микроструктуры — на странице Книга ордеров.
• Игры и социальные приложения. Параллель и скорость повышают «чувствительность» интерфейсов: внутриигровые рынки, аукционы, мэчинг, ленты активности.
• Платёжные/массовые сценарии. По мере роста экосистемы оракулов/стейблов — транзакции «повседневного» уровня становятся реалистичными по задержкам.
• DeFi-ядро (AMM, DEX-агрегаторы, RFQ). Быстрые блоки и throughput улучшают котирование и уменьшают «дырки» ликвидности; см. DEX и Ликвидность.

Сравнение: Monad vs «традиционный» EVM-L1 и L2

Вывод: Monad предлагает «L2-подобные» задержки в L1-модели, с сохранением привычной семантики EVM и без необходимости доказательной публикации в L1. При этом риски и допущения — иные, чем в L2 (нет общей безопасности с Ethereum, а мосты выполняют «полноценную» роль).

Риски и «подводные камни»

• Зависимости транзакций. При «широких» конфликтах (много общих слотов) выгода параллели падает; возможны повторные исполнения части транзакций.
• Комиссионная модель по gas_limit. Некорректно выставленный лимит — переплата или неуспех; ориентируйтесь на симуляцию/подсказки RPC.
• MEV. Быстрый блок не отменяет сэндвич-рисков: используйте приватные отправки/меньшие допуски по slippage — подробности на DEX.
• Сетевой/дисковый профиль. Нужны быстрые NVMe и стабильные каналы; при деградации железа узел теряет долю участия.
• Экосистема на старте. На раннем этапе часть инструментов/интеграций «догоняет» (индексаторы, оракулы, мосты) — это типично для свежего L1.

Быстрый старт для разработчика

1. Оцените «архитектуру под нагрузку»: если dApp интенсивно читает/пишет состояние, MonadDb + параллель могут дать заметный выигрыш.
2. Проведите трассировку горячих путей: при высокой частоте вызовов однотипного кода JIT-компиляция сократит время CPU; учитывайте «прогрев».
3. Адаптируйте лимиты газа к модели «charge by gas_limit» и заложите запас.
4. Проверьте совместимость: bytecode-совместимость упрощает перенос, но тесты с «необычными» опкодами/паттернами проводить обязательно.
5. Продумайте индексацию и кэш: high-TPS сеть требует аккуратной работы индексаторов/сабграфов.
6. Планируйте обновления клиента: молодая сеть будет активно оптимизироваться — держите CI/CD для нод.

FAQ

Как Monad сохраняет детерминизм EVM при параллельном исполнении? Транзакции исполняются параллельно оптимистически с фиксацией прочитанных/изменённых слотов. Коммит результатов идёт строго по порядку; при конфликте входов проблемная транзакция переисполняется. Это гарантирует совпадение результата с «как если бы» всё выполнялось последовательно.

Почему в Monad списание газа завязано на

, а не на фактический расход? Из-за асинхронного конвейера лидер не знает итоговый расход во время упаковки блока. Списание по лимиту закрывает атакующие сценарии и упрощает инварианты безопасности; UX компенсируется симуляцией, рекомендациями по газу и механизмом резервного баланса на ближайшие блоки.

Какие кейсы больше всего выигрывают от ~0,4 с блоков и ~0,8 с финализации? Торговля с ордербуком/перпетами, аукционы, игры, социальные и платежные приложения — всё, где «реакция интерфейса» и уверенность результата важнее максимальной пропускной способности в одном вызове.

Как сравнить Monad с L2-роллапами Ethereum? Monad — L1 со своей безопасностью; роллапы наследуют безопасность Ethereum L1, но платят латентностью/стоимостью публикации данных и сложностью мостов. Выбор зависит от доверительной модели и требований вашего приложения.

Есть ли риски централизации из-за железа? Требования к узлам умеренные (16 ядер/32 ГБ/2×NVMe), упор — на «умный» клиент; экосистема следит, чтобы рост производительности не зависел от редкого «премиум-железа». На практике мониторьте IOPS/сеть и планируйте апгрейды.

Словарь кратких терминов

• MonadBFT — консенсус BFT-класса, рассчитанный на короткие блок-интервалы и устойчивость к хвостовым форкам.
• RaptorCast — протокол эффективной доставки блоков между участниками.
• Оптимистическое параллельное исполнение — параллель EVM-вызовов с проверкой конфликтов на коммите и выборочной переисполнением.
• MonadDb — специализированная база для хранения состояния EVM-сети с асинхронным I/O и «тонким» доступом к слотам.
• JIT-компиляция — сборка повторно используемых контрактов в нативный код для ускорения исполнения.

См. также

• Децентрализованные биржи (DEX)
• Книга ордеров
• Ликвидность