Разработка модели кластеризации криптовалют по поведению

Кластеризация криптовалют: где поведенческая модель ошибается

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

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

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

Третий — дрейф самой сети. Изменение структуры комиссий, переход пользователей на новые типы адресов, рост доли пакетных операций сдвигают распределение признаков. Модель, обученная на прошлом срезе, теряет точность на текущем: пороги, которые раньше разделяли, теперь смешивают классы.

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

Что даёт модель: точность атрибуции и скорость разбора

Эффект модели измеряется не «умностью» алгоритма, а тремя числами: долей верных объединений адресов в кластеры, временем на разбор одной цепочки и объёмом адресов, которые пришлось размечать руками. Точность атрибуции держим на уровне, где ложная склейка — исключение: ошибочное объединение тянет чужие транзакции во все отчёты, поэтому спорный случай система оставляет раздельным.

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

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

Класс спорных случаев остаётся и сознательно не автоматизируется: микшеры с равными долями, мосты между сетями, депозиты бирж с общим адресом пополнения. Они уходят в ручную проверку с объяснением, почему кластер не слит — это и есть цена точности, заметная в отчёте.

Подходы к кластеризации криптовалют: правила, признаки, обучение

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

Ниже — три варианта, между которыми реально выбирают на старте.

Три варианта и их ограничения

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

Как мы строим модель: этапы работ от аудита данных до передачи

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

1. Аудит данных. Сводим источники: события сети, балансы и активность адресов, движения средств через биржи, историю торгов. Проверяем полноту, пропуски, дубли, часовые пояса и откаты блоков — иначе кластеризация криптовалют воспроизводит артефакты сбора, а не поведение.
2. Схема признаков. Задаём окна наблюдения и считаем по ним интенсивность транзакций, концентрацию держателей, оборачиваемость, долю крупных адресов, реакцию на волатильность. Признаки нормируем и фиксируем источник каждого — так активы с разной капитализацией становятся сопоставимыми.
3. Сборка модели. Подбираем метрику близости, число кластеров и устойчивость к выбросам, проверяем стабильность разбиения на подвыборках и при сдвиге окна.
4. Валидация на отложенной выборке. Делим данные по времени, а не случайно: обучение на прошлом, проверка на последующем периоде. Это исключает заглядывание в будущее и показывает, сохраняется ли структура кластеров.
5. Интерпретация. Сверяем кластеры с известными категориями — биржевые, стейблкоины, инфраструктурные, спекулятивные — и даём читаемые имена, иначе результат не переносится в решения.
6. Передача и обучение. Отдаём код, схему признаков, регламент пересчёта и мониторинг дрейфа, обучаем команду заказчика — модель остаётся рабочей без нас.

Артефакты передачи: конфигурации, схемы, регламенты и разметка

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

• Рабочая модель — обученные веса, скрипт запуска и зафиксированное окружение: результат воспроизводится на данных заказчика, а не только у нас в песочнице.
• Описание признаков — словарь с формулами: какие ончейн- и рыночные показатели считаются, за какое окно агрегации, как обрабатываются пропуски и выбросы.
• Правила объединения — метрика близости профилей, порог слияния и минимальный размер кластера: разметку можно пересобрать и получить тот же результат.
• Эталонная разметка — адреса и токены с метками и датой среза; на ней прогоняют каждую новую версию и сравнивают поведение со старой.
• Пороги срабатывания — что считается сменой поведения, при каком значении уходит сигнал и кто его получает.
• Регламент переобучения — периодичность, триггеры по дрейфу распределения, порядок валидации и публикации новой версии.
• Инструкции по сопровождению — развёртывание, мониторинг, откат на предыдущую версию и карточка модели с границами применимости.

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

Кейс: как модель сократила долю ложных срабатываний

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

Что показала контрольная выборка

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

Что изменили и что стало

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

После внедрения доля ложных срабатываний на той же выборке упала до 9%, полнота выросла до 0,84. Разбор спорной группы сократился с часов до 20–30 минут: аналитик получает готовый кластер с обоснованием, а не список адресов.

Честно про ограничения: на молодых адресах с короткой историей модель возвращает «недостаточно данных» вместо догадки — такие случаи уходят на ручной разбор, и это осознанное решение, а не пробел. Контрольную выборку пересобираем по мере появления новых типов поведения, иначе метрики перестают отражать реальность.

Чем кластеризация адресов отличается от атрибуции кошелька?

Кластеризация адресов отвечает на вопрос «какие адреса принадлежат одному участнику», а атрибуция кошелька — «кто этот участник». Первый шаг работает только с данными блокчейна: транзакциями и связями между ними. Второй подключает внешний контекст и превращает обезличенный кластер в биржу, сервис или конкретного владельца.

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

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

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

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

Технические сомнения: качество данных, разметка, приватность

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

Как проверяете качество разметки выборки?

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

Что с приватностью транзакций?

Работаем с агрегатами: адреса псевдонимизируются, в признаки уходят распределения, доли и интервалы. Сырые адреса и связки «кошелёк — личность» в модель не подаются и не покидают контур заказчика; схему обработки согласуем до старта.

Сохранится ли результат при обновлении данных?

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

Обсудим задачу: что нужно для старта работ

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

• Список сетей и активов: какие блокчейны и токены в периметре и сколько их — от этого зависит объём снимков и время подготовки данных.
• Горизонт и шаг наблюдения: за какой период берём активность и с какой частотой пересчитываем — день, неделя или месяц.
• Источники: есть ли свои архивы транзакций или собираем с публичных обозревателей; нужны ли биржевые метрики по торгам и ликвидности.
• Доступы: ключи к API, узлы, выгрузки в файлах — что уже есть, а что нужно организовать.
• Известные группы: активы, которые вы точно относите к одной категории (стейблкоины, биржевые токены) — на них проверяем, что модель различает очевидное.
• Признаки и критерий похожести: поведение адресов, распределение держателей, частота и объём переводов — что для вас важнее.
• Формат результата: разметка активов по группам, отчёт с профилями кластеров или регулярный пересчёт по новым данным.
• Ограничения: приватность, требования к хранению данных, нужна ли объяснимость решения и выгрузка в вашу систему.

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