Mono Audit logo
Статьи > Он-чейн мониторинг для Web3 безопасности

Июл 16, 2025

Он-чейн мониторинг для Web3 безопасности

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

Под понятие он-чейн мониторинга подпадает широкий спектр задач, от простого подсчета TVL или капитализации, до передовых подходов в автоматизированном предотвращении атак непосредственно в момент возникновения угрозы.

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

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

Цели мониторинга

Финансовые показатели

Базовым сценарием для любого web3 протокола в использовании он-чейн мониторинга является сбор данных для таких показателей как TVL, PoR и объемы проходящие через протокол.

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

Производительность и жизненные показатели протокола

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

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

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

Обнаружение угроз и инцидентов

Наиболее продвинутые системы мониторинга способны обнаруживать попытки атак до или в процессе их выполнения.

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

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

Отслеживаемые значения

Базовые значения

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

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

Анализ инвариантов протокола производится на основе данных полученных от считывания базовых значений.

Качественные характеристики

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

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

Дополнительные значения

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

Типы размещения системы мониторинга

In-house

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

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

SaaS

В большинстве же случаев использование авангардных SaaS продуктов является оптимальным выбором.

Передовые решения от флагманов индустрии дадут вам доступ к технологиям отточенным в узкоспециализированных командах, прошедших проверку временем.

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

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

Hybrid

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

Источники данных для мониторинга

Вне зависимости от того какой тип системы вы планируете использовать, SaaS или In-house, вы должны понимать откуда именно вы получаете данные блокчейна.

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

RPC/Node

Так для In-house системы вы можете использовать доступ к бесплатным или платным RPC-провайдерам, провайдерам нод, либо же крутить собственную ноду блокчейна. Каждый из вариантов имеет разные лимиты по использованию, а также стоимость.

В случае SaaS решения вам стоит уточнить у вашего поставщика какие источники он использует. Топовые сервисы используют грядки собственных нод.

Block/mempool

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

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

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

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

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

Результаты мониторинга

Данные по требованию

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

Оповещения и тревоги

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

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

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

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

Автоматические действия

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

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

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

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

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

Разработка дорожной карты безопасности для Web3

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