Кластеризація криптовалют: де поведінкова модель помиляється
Кластеризація криптовалют спирається на евристики графа транзакцій: спільний вхід в одній операції, адреса здачі, повторне використання ключа.
Поведінкові ознаки адрес — ритм активності, розмір переказів, коло контрагентів, частка вхідних із пакетними виплатами — уточнюють картину там, де зв'язки обриваються.
Але кожне припущення має межу, за якою хибні спрацювання моделі зростають швидше, ніж охоплення: кластер із неправильною міткою гірший, ніж відсутність мітки, бо на нього спираються рішення щодо ризику та лістингу.
Перший розрив — змішування потоків усередині сервісів. Кастодіальні гаманці, біржові гарячі адреси та масові виплати зводять кошти тисяч клієнтів в один вхід. Евристика спільних входів склеює їх в один вузол, і модель приписує сервісному контуру поведінку одного власника.
Ознаки сервісу при цьому читабельні: регулярність за часом, рівні розміри, збіг із графіком виплат — їх варто віднімати до, а не після кластеризації.
Другий — мультипідписи та контрактні гаманці: адресою керують кілька ключів, поріг підписів змінюється за рішенням власників. Граф рветься під час ротації складу і, навпаки, дає хибні зв'язки, коли один учасник перевикористовує свій ключ у різних схемах.
Транзитні адреси додають шуму: вони поводяться як здача, але слугують лише для перекидання коштів між контурами й не несуть поведінки кінцевого власника.
Третій — дрейф самої мережі. Зміна структури комісій, перехід користувачів на нові типи адрес, зростання частки пакетних операцій зсувають розподіл ознак. Модель, навчена на минулому зрізі, втрачає точність на поточному: пороги, які раніше розділяли, тепер змішують класи.
Розбираємо, як це закривається: які ознаки валідуємо на графі вручну, як калібруємо пороги і що вважаємо допустимою часткою хибних спрацювань.
Що дає модель: точність атрибуції та швидкість розбору
Ефект моделі вимірюється не «розумністю» алгоритму, а трьома числами: часткою правильних об'єднань адрес у кластери, часом на розбір одного ланцюжка та обсягом адрес, які довелося розмічати вручну.
Точність атрибуції тримаємо на рівні, де хибне склеювання — виняток: помилкове об'єднання тягне чужі транзакції в усі звіти, тому спірний випадок система залишає розділеним.
Швидкість розбору ланцюжків змінюється якісно. На вході — граф зі зібраними кластерами та мітками бірж, міксерів і сервісів, а робота зводиться до перевірки гіпотез замість ручного проходу по переказах.
Ланцюжок середньої глибини розбирається за хвилини, і розбір стає відтворюваним: той самий маршрут коштів інший інженер повторює за тими самими правилами.
Зменшення ручного розмічання та обсяг реєстру адрес пов'язані напряму.
Нові адреси розмічаються за поведінкою — збіг входів, тайминги, повторне використання адреси для здачі, — а реєстр накопичує результат: підтверджена мітка розширює кластер, і схожий випадок уже не потребує людини.
Клас спірних випадків залишається і свідомо не автоматизується: міксери з рівними частками, мости між мережами, депозити бірж зі спільною адресою поповнення. Вони йдуть у ручну перевірку з поясненням, чому кластер не злито — це і є ціна точності, помітна у звіті.
Підходи до кластеризації криптовалют: правила, ознаки, навчання
Вибір підходу визначається не складністю моделі, а тим, які дані є на вході й хто підтримуватиме результат далі.
Якщо розміченої вибірки немає і заздалегідь неясно, які класи взагалі існують, навчання з учителем перетворюється на ручне розмічання наосліп — а воно застаріває швидше, ніж окупається.
Нижче — три варіанти, між якими реально обирають на старті.
Три варіанти та їхні обмеження
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Евристики кластеризації: пороги за обсягом переказів, часткою операцій із біржами, кількістю активних адрес | Потрібен швидкий старт, мало даних, важлива пояснюваність кожного рішення | Пороги задаються вручну, ламаються при зміні поведінки учасників, не масштабуються на нові типи |
| Навчання з учителем на розміченій вибірці | Є історичні мітки: біржі, стейблкоїни, ігрові токени | Розмічання дороге, рідкісні класи залишаються непокритими, мітки швидко розходяться з реальністю |
| Навчання без учителя на графових ознаках переказів | Міток немає, але є зв'язний граф транзакцій між адресами | Потребує регулярного перерахунку графа, чутливе до якості нормалізації адрес |
На практиці підходи комбінують: евристики дають первинні мітки, навчання з учителем уточнює межі між ними, графові ознаки додають контекст переказів, невидимий в окремо взятій адресі.
Критерій приймання — стійкість кластерів: якщо при зсуві вікна спостереження склад груп змінюється незначно, модель можна ставити в моніторинг, а не перезбирати щомісяця.
Як ми будуємо модель: етапи робіт від аудиту даних до передачі
Етапи впровадження моделі йдуть у фіксованому порядку: спочатку переконуємося, що дані описують саме поведінку, і лише потім будуємо розбиття.
Помилка в ознаках на першому кроці не виправляється ні вибором алгоритму, ні підбором кількості кластерів — тому аудит даних і схема ознак займають більше часу, ніж саме збирання.
- Аудит даних. Зводимо джерела: події мережі, баланси й активність адрес, рух коштів через біржі, історію торгів. Перевіряємо повноту, пропуски, дублі, часові пояси та відкати блоків — інакше кластеризація криптовалют відтворює артефакти збору, а не поведінку.
- Схема ознак. Задаємо вікна спостереження й рахуємо за ними інтенсивність транзакцій, концентрацію власників, оборотність, частку великих адрес, реакцію на волатильність. Ознаки нормуємо й фіксуємо джерело кожної — так активи з різною капіталізацією стають порівнюваними.
- Збирання моделі. Підбираємо метрику близькості, кількість кластерів і стійкість до викидів, перевіряємо стабільність розбиття на підвибірках і при зсуві вікна.
- Валідація на відкладеній вибірці. Ділимо дані за часом, а не випадково: навчання на минулому, перевірка на наступному періоді. Це виключає зазирання в майбутнє й показує, чи зберігається структура кластерів.
- Інтерпретація. Звіряємо кластери з відомими категоріями — біржові, стейблкоїни, інфраструктурні, спекулятивні — і даємо читабельні імена, інакше результат не переноситься в рішення.
- Передача та навчання. Віддаємо код, схему ознак, регламент перерахунку й моніторинг дрейфу, навчаємо команду замовника — модель залишається робочою без нас.
Артефакти передачі: конфігурації, схеми, регламенти та розмітка
Передаємо не «модель на словах», а комплект, за яким команда замовника запускає, перевіряє й розвиває рішення без нас. Код, конфігурації, розмітка й документи лежать в одному репозиторії та версіонуються разом — розбіжностей між тим, що описано, і тим, що працює, не залишається.
- Робоча модель — навчені ваги, скрипт запуску й зафіксоване середовище: результат відтворюється на даних замовника, а не лише в нас у пісочниці.
- Опис ознак — словник із формулами: які ончейн- і ринкові показники рахуються, за яке вікно агрегації, як обробляються пропуски та викиди.
- Правила об'єднання — метрика близькості профілів, поріг злиття й мінімальний розмір кластера: розмітку можна перезібрати й отримати той самий результат.
- Еталонна розмітка — адреси й токени з мітками та датою зрізу; на ній проганяють кожну нову версію й порівнюють поведінку зі старою.
- Пороги спрацювання — що вважається зміною поведінки, за якого значення йде сигнал і хто його отримує.
- Регламент перенавчання — періодичність, тригери за дрейфом розподілу, порядок валідації та публікації нової версії.
- Інструкції із супроводу — розгортання, моніторинг, відкат до попередньої версії та картка моделі з межами застосовності.
Комплект знімає залежність від підрядника: набір ознак, пороги й розмітку можна змінювати своїми силами, а не перезбирати рішення з нуля.
Кейс: як модель скоротила частку хибних спрацювань
Задачу принесла команда, яка розмічала потік адрес вручну: набір правил за порогами суми, частотою операцій і віком гаманця.
Ціна такого підходу була зрозуміла відразу — майже кожне третє спрацювання йшло в розбір як хибне, а одна спірна група адрес займала в аналітика кілька годин. При зростанні потоку правила доводилося дописувати, і вони починали суперечити одне одному.
Що показала контрольна вибірка
Ми зафіксували вибірку адрес, розмічених вручну, і не змінювали її між версіями — інакше метрики немає з чим порівнювати.
На ній правила давали частку хибних спрацювань близько третини та повноту за цільовими групами 0,61: частина схем просто не потрапляла в розмітку, бо не вкладалася в пороги.
Що змінили і що стало
Модель кластеризації за поведінкою рахує ознаки з історії операцій: ритм активності, склад контрагентів, частка транзитних переказів, щільність зв'язків усередині групи.
Кластери будуються без учителя, ручна розмітка залишилася лише для перевірки якості — звіряли її й з відкритими наборами Chainalysis.
Після впровадження частка хибних спрацювань на тій самій вибірці впала до 9%, повнота зросла до 0,84. Розбір спірної групи скоротився з годин до 20–30 хвилин: аналітик отримує готовий кластер з обґрунтуванням, а не список адрес.
Чесно про обмеження: на молодих адресах із короткою історією модель повертає «недостатньо даних» замість здогаду — такі випадки йдуть на ручний розбір, і це усвідомлене рішення, а не прогалина.
Контрольну вибірку перезбираємо в міру появи нових типів поведінки, інакше метрики перестають відображати реальність.
Чим кластеризація адрес відрізняється від атрибуції гаманця?
Кластеризація адрес відповідає на питання «які адреси належать одному учаснику», а атрибуція гаманця — «хто цей учасник». Перший крок працює лише з даними блокчейну: транзакціями та зв'язками між ними.
Другий підключає зовнішній контекст і перетворює знеособлений кластер на біржу, сервіс або конкретного власника.
Усередині кластеризації працюють поведінкові евристики. Спільне витрачання входів об'єднує адреси, підписані однією транзакцією; повторне використання адреси для приймання, типові патерни здачі та корельований час операцій додають зв'язків у граф.
Формально це графова кластеризація з вагою в кожного ребра: рішення про об'єднання ухвалюється за сумою ознак, а не за одним збігом.
Атрибуція гаманця йде від точок опори — адрес депозитів бірж, даних верифікації клієнтів, публічних заяв проєктів, тегів в оглядачах на кшталт Etherscan. Ідентифікація власника — це зіставлення готового кластера з цими мітками. Окрема адреса без кластеризації покриває одну транзакційну гілку й майже не дає висновків.
Різницю підходів видно за ціною помилки. Кластеризація помиляється хибним злиттям: два різні учасники стають одним, і помилка тиражується по всіх зв'язках. Атрибуція помиляється хибною міткою: сервіс приписано не тому кластеру.
Тому кластеризацію перевіряють на повноту охоплення й на стійкість до міксерів, які ламають евристику спільного витрачання входів, а атрибуцію — на точність мітки.
Порядок робіт завжди один: спочатку будується кластерний граф, потім на нього накладаються мітки. Тоді ідентифікація власника спирається на поведінку мережі, а не на здогад за однією адресою.
Технічні сумніви: якість даних, розмітка, приватність
Кластеризація криптовалют спирається на поведінкові ознаки: розподіл обсягів за адресами, регулярність транзакцій, концентрацію у великих власників. Чим брудніші дані та менше розмічених прикладів, тим вищий шанс, що модель знайде стійкі групи там, де їх немає.
Що робити, якщо історія транзакцій неповна?
Пропуски не добудовуємо здогадами. Ознаки рахуємо за вікнами з достатньою щільністю даних, а «діряві» періоди позначаємо як непевні — вони не входять у підсумкову сегментацію, але видимі у звіті. Додатково звіряємо кілька джерел, щоб викид одного не розійшовся по всій вибірці.
Як перевіряєте якість розмітки вибірки?
Критерії віднесення до групи описуємо до старту, спірні випадки розбираємо окремо. Частину вибірки розмічають незалежно, щоб виміряти узгодженість, а не спиратися на рішення однієї людини.
Стійкість перевіряємо перерахунком на підвибірках і зсунутих вікнах: якщо групи розпадаються, ознаки перезбираємо.
Що з приватністю транзакцій?
Працюємо з агрегатами: адреси псевдонімізуються, в ознаки йдуть розподіли, частки та інтервали. Сирі адреси та зв'язки «гаманець — особистість» у модель не подаються й не залишають контур замовника; схему обробки узгоджуємо до старту.
Чи збережеться результат при оновленні даних?
Фіксуємо набір ознак, параметри відбору та склад вибірки, зберігаємо контрольні прогони. При нових періодах даних порівнюємо розбиття з попереднім: частка об'єктів, що перейшли між групами, — вимірюваний показник стабільності, і він іде у звіт, а не залишається на словах.
Обговоримо задачу: що потрібно для старту робіт
Щоб повернутися з оцінкою термінів і планом робіт, а не з вилкою «плюс-мінус», нам потрібен набір ввідних про дані та про те, яке рішення ви чекаєте. Чим конкретніші вхідні дані, тим точніші етапи: підготовка ознак, навчання, перевірка стійкості кластерів, видача результату.
- Список мереж і активів: які блокчейни й токени в периметрі та скільки їх — від цього залежить обсяг знімків і час підготовки даних.
- Горизонт і крок спостереження: за який період беремо активність і з якою частотою перераховуємо — день, тиждень чи місяць.
- Джерела: чи є власні архіви транзакцій або збираємо з публічних оглядачів; чи потрібні біржові метрики щодо торгів і ліквідності.
- Доступи: ключі до API, вузли, вивантаження у файлах — що вже є, а що потрібно організувати.
- Відомі групи: активи, які ви точно відносите до однієї категорії (стейблкоїни, біржові токени) — на них перевіряємо, що модель розрізняє очевидне.
- Ознаки та критерій схожості: поведінка адрес, розподіл власників, частота й обсяг переказів — що для вас важливіше.
- Формат результату: розмітка активів за групами, звіт із профілями кластерів або регулярний перерахунок за новими даними.
- Обмеження: приватність, вимоги до зберігання даних, чи потрібна пояснюваність рішення та вивантаження у вашу систему.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом робіт: етапами, складом даних і критерієм приймання.
