Sonic – EVM-совместимый блокчейн первого уровня, который продолжает техническую линию Fantom, но работает как новая сеть с собственным состоянием, валидаторами и токеном S. Его консенсус сочетает Proof of Stake, асинхронный обмен событиями в DAG и финальную линейную запись. Экосистема дополняет это нативным мостом к Ethereum и программой возврата комиссии разработчикам.
Sonic нельзя считать обычным переименованием Opera. Контракты и балансы не перенеслись в тот же реестр автоматически, а FTM обменивается на S отдельными маршрутами. Адрес пользователя может совпадать из-за EVM, но активы, nonce и история в двух сетях независимы. Это тот же принцип, который объяснён в статье про один адрес в разных EVM-сетях.
Как работает консенсус Sonic
Валидаторы блокируют S и создают собственные event blocks с транзакциями. Они асинхронно обмениваются событиями, формируя локальные ориентированные ациклические графы. Узлу не нужно ждать единственного лидера для каждого промежуточного пакета, поэтому несколько валидаторов распространяют работу параллельно.
Когда событие получило достаточное подтверждение от сети, оно становится root event и включается в общий порядок. Финальная main chain хранит последовательность подтверждённых транзакций, которую видит EVM и обозреватель. DAG используется внутри механизма согласования, а пользователь работает с привычными блоками, receipts, nonce и gas.
Безопасность опирается на Proof of Stake и aBFT. Злоумышленник должен получить значительный вес S и рискует залогом. По текущим параметрам самостоятельный валидатор вносит не менее 500 000 S, а общий делегированный stake ограничен относительно self-stake. Высокий порог упрощает раннюю устойчивость операторов, но ограничивает доступ к производству блоков.
EVM, SonicVM и база состояния
Sonic исполняет Solidity и Vyper и поддерживает Ethereum-инструменты через JSON-RPC. Транзакция содержит chain ID 146, nonce, gas limit и fee-параметры. Совместимость кода не означает одинаковое окружение: адреса внешних контрактов, оракулы, мосты и ликвидность нужно заново проверять для Sonic.
Производительность опирается не только на DAG. Команда оптимизировала виртуальную машину и хранение состояния, известное как Carmen, а позднее развивала SonicDB. Заявленные сотни тысяч транзакций в секунду относятся к определённым тестам и типам нагрузки. Реальная пропускная способность приложения зависит от сложности EVM-вызова, размера состояния, валидаторов, RPC и индексаторов.
Субсекундная финальность также не гарантирует мгновенный интерфейс. dApp может ждать индексатор или обработку события. Для диагностики нужно сверить receipt, status и finalized block, а не ориентироваться только на анимацию кошелька.
Sonic Gateway
Sonic Gateway – нативный мост между Ethereum и Sonic. Пользователь вносит актив на исходной стороне, после финальности депозит попадает в очередной heartbeat, затем на стороне назначения доступен claim. Пакетная обработка экономит gas, но добавляет ожидание; Fast Lane может инициировать дополнительный heartbeat.
Мост регулярно записывает в Ethereum Merkle root и высоты обеих сетей. Если Gateway или Sonic не работает 14 дней подряд, fail-safe позволяет доказать право на исходные активы и забрать их в Ethereum. Этот срок встроен в контракт и не описывается как период оспаривания транзакций Sonic.
Защита относится только к активам, прошедшим через Sonic Gateway. Если пользователь обменял полученный токен в DeFi или применил сторонний мост, исходная гарантия не следует за новым активом. Любой перевод нужно проверять как две связанные транзакции, по правилам статьи о том, почему у моста два TxID.
Fee Monetization
Fee Monetization, или FeeM, позволяет одобренному приложению получать 90 процентов сетевых комиссий, созданных зарегистрированными контрактами. Оставшиеся 10 процентов направляются валидаторам. В отличие от Ethereum, base fee в этой модели не сжигается автоматически.
Учёт выполняется специальным контрактом и группой off-chain oracles, которые отслеживают расход gas внутри вызовов и подтверждают сумму при claim. Если одна транзакция проходит через несколько зарегистрированных приложений, вознаграждение делится по фактическому расходу gas, а не начисляется каждому повторно.
Модель создаёт доход разработчикам, но может стимулировать искусственное увеличение gas. Пользователь должен смотреть на полный fee quote и пользу операции. Участие dApp в FeeM не является аудитом, гарантией ликвидности или одобрением токена.
История
Технические корни Sonic находятся в Fantom, проекте, который развивался с 2018 года. Его сеть Opera использовала EVM, Proof of Stake и DAG-консенсус Lachesis. Со временем команда столкнулась с ограничениями базы состояния, синхронизации и стоимости инфраструктуры, которые нельзя было полностью устранить обычным soft fork.
В мае 2024 года был объявлен новый L1 под названием Sonic, а в августе организация сменила бренд Fantom Foundation на Sonic Labs. Sonic Foundation получила функции управления сетью и казначейством, Sonic Labs – разработку и рост экосистемы. Mainnet стартовала 18 декабря 2024 года, а награды Opera были перенаправлены валидаторам Sonic.
Первые 90 дней портал допускал обмен FTM и S в обе стороны, затем основной контрактный маршрут стал односторонним из FTM в S. В апреле 2026 года команда объявляла о завершении Opera-инфраструктуры в июне, но 23 июня отменила это решение после реакции сообщества. По последнему официальному обновлению Opera и её мост поддерживаются как минимум до конца 2026 года. Пользователю нужно проверять свежий статус маршрута перед миграцией.
Команда
Майкл Конг руководил Fantom, а затем Sonic Labs и отвечал за переход к новой сети. Андре Кронье присоединился к Fantom после основания проекта, был техническим советником, директором и CTO Sonic Labs и вёл разработку Sonic и Gateway. Официальное сообщение отдельно уточняет, что он не был основателем Fantom Foundation.
19 июня 2026 года Майкл Конг, Андре Кронье и Дэвид Ричардсон объявили об уходе из совета директоров и передаче операционных обязанностей. Они сохранили статус советников, но перестали принимать бизнес-решения. Новым CEO стал Мэтт Виссер, новым COO – Коста Куркумелис.
Профессор Бернхард Шольц и инженерная команда внесли ключевой вклад в виртуальную машину и систему хранения. Современный проект включает Sonic Labs, Sonic Foundation, валидаторов, разработчиков клиента и команды приложений. Поэтому старые страницы, где Майкл Конг указан действующим CEO, а Андре Кронье – CTO, уже не отражают управление на август 2026 года.
Токен S и миграция FTM
S оплачивает gas, блокируется валидаторами и делегаторами и заявлен как токен управления. При запуске владельцы FTM получили путь обмена один к одному. Это не означает, что FTM на любой сети автоматически является S: маршрут зависит от того, где лежит FTM – в Opera, Ethereum или на бирже.
С июня 2025 года действует дополнительный выпуск на программы роста – 47 625 000 S ежегодно в течение шести лет. Неиспользованная за год часть этой категории должна сжигаться. Валидаторские награды первые четыре года финансируются сохранённым резервом наград Opera, после чего документация предусматривает новую эмиссию для блоков.
Целевая доходность меняется в зависимости от доли застейканного предложения. Она не является фиксированным депозитом, а делегатор принимает риск валидатора, периода выхода и изменений параметров. Полную оценку следует строить через анализ токеномики, включая выпуск на рост, burn и казначейство.
Что проверить перед использованием
- Сеть. В кошельке должен быть Sonic с chain ID 146, а не Opera или Ethereum.
- Актив. Проверить контракт токена и происхождение через конкретный мост.
- Миграция. Выбрать маршрут FTM по исходной сети и свежему статусу официальной инфраструктуры.
- Gateway. Сохранить обе транзакции, дождаться heartbeat и выполнить claim.
- Контракт. Проверить approvals, прокси и административные роли приложения.
Для первой операции разумен тестовый перевод, но он должен проходить весь будущий маршрут, включая мост и обратный вывод. Подход описан в инструкции о том, как сделать тестовый перевод.
Основные риски
Первый риск – концентрация валидаторов из-за высокого self-stake и ранней стадии сети. Второй – мост: fail-safe уменьшает один сценарий потери, но не защищает сторонние маршруты, DeFi-позиции или ошибочную подпись. Третий – переход от Opera, где официальные сроки уже менялись.
FeeM добавляет зависимость от oracle-учёта и может искажать стимулы разработчиков. EVM переносит стандартные уязвимости контрактов, approvals, MEV и nonce. Наконец, токеномика сочетает миграцию FTM, программы выпуска, резервы наград и burn, поэтому один показатель APR не описывает давление предложения.
Итог: Sonic – самостоятельная быстрая EVM-сеть, а не обновлённое имя Opera. Её отличают DAG-консенсус, оптимизированное состояние, нативный Gateway и возврат комиссии приложениям. Главные компромиссы – молодой валидаторский набор, сложная миграция, мостовая зависимость и необходимость оценивать FeeM вместе с безопасностью и реальным спросом.
