Как протоколы находят Sybil-кошельки: методы детекции и ложные срабатывания

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

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

Зачем протоколам Sybil-фильтр

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

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

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

Анализ графа связей

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

Что в графе ищут в первую очередь:

Общие источники пополнения. Группа адресов, получивших первый депозит от одного адреса в короткий промежуток, — кандидат в кластер. Особый случай — контракты массовой рассылки, которые за одну транзакцию финансируют десятки получателей.
Цепочки переводов. Адрес A финансирует B, B финансирует C. Последовательная передача остатков по цепочке связывает все звенья в одну сущность.
Общие контрагенты. Несколько адресов регулярно переводят средства на один и тот же внешний адрес или получают с него — например, на один депозитный адрес биржи.
Консолидация. После раздачи токены с многих адресов стекаются в одну точку. Это самый читаемый признак, и некоторые проекты анализируют его уже после распределения.

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

Поведенческие эвристики и модели

Граф не ловит фермы, которые финансируются из разных источников. Для них используют признаки поведения — что и когда делает адрес, независимо от того, с кем он связан переводами.

Типичные эвристики:

Тайминг. Группа адресов совершает однотипные действия с интервалом в секунды или минуты, в одном порядке, в одни и те же дни недели или часы.
Одинаковые маршруты. Идентичная последовательность контрактов и функций, близкие суммы, одинаковое число транзакций. Реальные пользователи расходятся быстро; скрипт — никогда.
Профиль активности во времени. Адрес создан незадолго до кампании, активен ровно до снапшота, после — тишина. Отсутствие «жизни» до и после программы.
Минимальные пороги. Активность, подогнанная под слухи о критериях: ровно столько транзакций, ровно такой объём, и ни одной сверх того.
Однообразие. Единственный протокол, ни одного перевода другому человеку, ни NFT, ни доменов, ни голосований.

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

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

Hunter-программы и жалобы сообщества

Ряд протоколов дополняет собственный анализ внешним. Два формата встречаются чаще всего.

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

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

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

Важно понимать, что все три механизма работают уже после снапшота — на этапе, который в терминах CoinDropster соответствует статусу Verification. Как устроен сам снапшот и что в него попадает, разобрано в статье о снапшотах аирдропов.

Почему бывают ложные срабатывания

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

Общие сервисы. Биржи используют ограниченный пул адресов вывода. Тысячи независимых людей получают первый депозит с одного и того же горячего кошелька, и по признаку источника они неотличимы от фермы.
Публичные гайды. Когда сотни тысяч человек выполняют один и тот же список из семи шагов, их маршруты идентичны. Модель, обученная на «одинаковые маршруты = ферма», отнесёт к ферме и добросовестных участников.
Семьи и команды. Несколько человек, живущих вместе или работающих в одной компании, могут пополнять кошельки друг друга. На графе это один кластер.
Шум в данных. Ошибки индексации, неучтённые сети, контракты-агрегаторы, через которые проходят чужие средства, — всё это создаёт рёбра, которых в реальности нет.
Компромисс между ошибками. Любой фильтр настраивается между «пропустить ферму» и «исключить честного». Протокол, который хочет убрать почти все фермы, неизбежно заденет часть реальных пользователей — и наоборот.

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

Для пользователя из этого следует два вывода. Первый: исключение — это результат оценки вероятности, а не установленный факт, и оно может быть ошибочным. Второй: у большинства протоколов есть процедура пересмотра, и её стоит использовать, если есть что показать. Как она обычно устроена и что подготовить, — в статье о том, что делать, если кошелёк помечен как Sybil. Этап Verification, на котором происходит фильтрация и апелляции, CoinDropster отслеживает по каждому проекту как отдельный статус. Смотреть отслеживаемые аирдропы →