Чому система відстеження airdrop ламається на піку навантаження
Пік навантаження — це момент, коли снапшот балансів знімається не в той блок, що зафіксований у правилах роздачі. Учасник переказує токени між гаманцями в останні хвилини вікна, снапшот читає вже новий стан, і в розподіл потрапляють адреси, яких на момент фіксації не існувало.
Далі подвійне нарахування: один і той самий капітал враховується за двома адресами, а сумарна частка перевищує сто відсотків.
Друга точка відмови — втрата подій. При різкому зростанні кількості транзакцій індексер не встигає за блокчейном, частина переказів і додавань ліквідності випадає з обліку. Учасник, який усе зробив за правилами, недоотримує нагороду, а апеляцію розбирають вручну за логами.
Якщо облік ведеться в таблицях, відновлення займає дні: звіряти тисячі адрес очима — це не процес, а ручна робота, яка не масштабується і не дає гарантій відтворюваності.
Третя проблема — відсутність ідемпотентності. Повторний запуск розподілу після збою нараховує нагороди двічі, і відкотити це без знімка стану вже не можна.
Система, яка не зберігає історію снапшотів і не вміє перерахувати результат із вихідних даних, при першому ж інциденті перетворюється на джерело збитків і репутаційних втрат.
Розбираємо, як це закривається: детермінований снапшот за конкретним блоком, ідемпотентні операції нарахування з журналом, стійкий до навантаження індексер і автоматична звірка сум перед відправкою транзакцій.
Що дає вибудуваний трекінг і розподіл нагород
Швидкість снапшота та розрахунку часток
Снапшот балансів і активностей знімається за заздалегідь зафіксованою висотою блоку, а не «на око» в момент запуску розподілу. Це прибирає головне джерело суперечок: усі учасники бачать один і той самий стан мережі, і перерахунок часток іде за детермінованим правилом.
На практиці розрахунок снапшота за адресами з історією в десятки тисяч транзакцій укладається в хвилини замість годин ручної звірки, а результат відтворюється повторним прогоном на тій самій висоті — це і є перевірюваність.
Частка помилок нарахування та розбір спірних кейсів
Помилкові нарахування майже завжди походять із трьох місць: невраховані перекази між своїми адресами, нагороди за дії в пов'язаних протоколах і граничні випадки з частковими виводами.
Коли правила нарахування описані формально й перевіряються автотестами на історичних даних, частка помилкових нарахувань падає до одиниць на тисячу — решта ловиться до публікації списку, а не після.
Спірний кейс розбирається за логом: видно, які дії адреси потрапили у вибірку, які відсіклися і за якою умовою. Час на розбір скорочується з годин листування до кількох хвилин — відповідь підкріплена даними, а не обіцянками.
Стійкість до піків навантаження
Пік інтересу припадає на перші години після оголошення — тисячі адрес одночасно перевіряють право на нагороду.
Система трекінгу тримає таке навантаження завдяки кешуванню результатів і розділенню читання та запису: перевірка права на нагороду не перераховує всю історію заново, а віддає підготовлену відповідь.
Це знімає ризик, що в найпомітніший момент інтерфейс перевірки впаде і частина учасників піде, не дочекавшись відповіді.
Передбачуваність розподілу
Вибудуваний трекінг перетворює розподіл із разової акції на повторюваний процес: правила, снапшот і перевірка прав описані та перевикористовуються в наступних раундах.
Замовник отримує не разовий список адрес, а механізм, який масштабується на нові кампанії без переписування логіки з нуля.
Варіанти архітектури airdrop-трекінгу та їхні обмеження
Вибір підходу визначає, наскільки система стійка до перерахунків і як швидко ви відповідаєте на спір учасника. Три базові варіанти: рахувати напряму за логами мережі, вести облік у внутрішній базі або комбінувати обидва з періодичною звіркою. Нижче — коли який працює і де ламається.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Облік за логами мережі | Разові кампанії, невелика кількість учасників, потрібна максимальна прозорість | Кожен перерахунок — повторне читання історії; за високої активності вузьке місце — швидкість вибірки, а не логіка |
| Внутрішня база | Регулярні кампанії, складні правила нарахування, потрібні швидкі звіти | Дані живуть окремо від мережі: розходження з реальними транзакціями накопичується непомітно |
| Гібридна схема | Тривалі програми, часті snapshot, спірні кейси | Потребує регламенту звірки та обробки розходжень — інакше втрачається сенс гібрида |
Де ламається кожен підхід
Облік за логами точний за визначенням, але погано масштабується: чим довша історія і активніша мережа, тим дорожчий кожен snapshot.
Внутрішня база швидка, зате розходиться з мережею при реорганізаціях і пропущених подіях — а розходження спливає в момент розподілу, коли оспорювати вже пізно.
Гібридна схема знімає обидві крайнощі: гарячі запити йдуть по базі, а періодична звірка підтверджує, що враховані операції збігаються з логами. Ключове тут — регламент звірки: як часто, за яким вікном і що робити з виявленими розходженнями. Без нього гібрид перетворюється на ту саму внутрішню базу, тільки з зайвим шаром.
Розбираємо, як вибрати схему під ваш сценарій і закласти звірку так, щоб розподіл витримував перевірку.
Етапи впровадження: від аудиту даних до передачі регламентів
Впровадження системи airdrop-трекінгу — це не встановлення софту, а послідовність інженерних рішень, де кожен наступний крок спирається на попередній. Нижче — як виглядає робочий процес від першого розбору даних до моменту, коли ваша команда веде систему самостійно.
- Аудит джерел. Розбираємо, звідки беруться дані про держателів та активність: вузли мережі, індексатори, вивантаження з біржових і гаманцевих сервісів. Фіксуємо, які адреси та події взагалі доступні, де дані неповні та які розбіжності потрібно закрити до старту.
- Схема снапшоту. Визначаємо момент фіксації стану мережі та правило, за яким адреса потрапляє у вибірку: мінімальний баланс, утримання позиції, виключення службових і біржових адрес. Схема снапшоту має бути відтворюваною — один і той самий блок дає один і той самий результат при повторному прогоні.
- Правила нарахування. Формалізуємо формулу розподілу: ваги за обсягом, коефіцієнти за тривалість утримання, пороги відсікання. Правила описуємо так, щоб їх можна було перевірити на тестовій вибірці та пояснити учаснику, чому він отримав саме стільки.
- Налаштування та запуск. Збираємо розрахунковий модуль, підключаємо джерела, налаштовуємо журналювання кожної транзакції нарахування. Будь-яка зміна правил проходить через версіонування — стара версія залишається доступною для звірки.
- Перевірка на історичних даних. Прогоняємо правила на минулих снапшотах і звіряємо результат з фактичними розподілами. Так виявляються подвійні нарахування, загублені адреси та крайові випадки до того, як вони зачеплять реальних учасників.
- Передача регламентів. Віддаємо документацію щодо схеми снапшоту, формул і порядку оновлення правил, навчаємо вашу команду проводити розрахунки та розбирати спірні нарахування самостійно.
Така послідовність знімає головний ризик — розбіжність між обіцяним і нарахованим. Кожен етап закінчується артефактом, який можна перевірити, а не усним узгодженням.
Що замовник отримує на руки після впровадження
Впровадження вважається завершеним не в момент, коли система запустила перший розподіл, а коли команда замовника може провести наступний самостійно — без нас.
Тому передаємо не «доступ до панелі», а повний комплект артефактів: конфігурації, правила, схеми та регламенти, за якими систему можна експлуатувати, перевіряти й розвивати.
- Конфігурація снапшота — зафіксовані параметри зняття стану: момент фіксації, глибина історії, список адрес і винятків, поведінка при повторному запуску. Знімок відтворюється один в один, тому спірний результат завжди можна перерахувати.
- Правила нарахування — формалізовані умови розподілу: ваги, пороги відсікання, множники за активність, обробка граничних випадків. Кожне правило описано так, що його можна змінити без правки коду.
- Схема потоків даних — звідки надходять дані щодо балансів і транзакцій, де відбувається звіряння, куди йде результат розподілу. Видно, на якому кроці виникає розбіжність і як її локалізувати.
- Регламент звіряння — порядок перевірки підсумків: контрольні суми, вибірка для ручної перевірки, критерії зупинки розподілу при розбіжності. Звіряння виконується за кроками, а не «на око».
- Документація для підтримки — опис типових збоїв, порядок відкату до попереднього снапшота, точки логування, контакти відповідальних. Черговий інженер розбирається за інструкцією, без дзвінка нам.
- Розмежування доступів — ролі на перегляд, запуск і зміну правил, журнал дій за кожною операцією. Хто і коли змінював умови нарахування, видно постфактум.
- План розвитку — що закладено на майбутні раунди: нові джерела даних, додаткові метрики активності, сценарії повторного розподілу.
Комплект передаємо в репозиторій замовника разом з історією змін — артефакти живуть у його контурі, а не в нас. Опишіть задачу: повернемося з оцінкою та планом, який обсяг документації й регламентів потрібен саме під ваш процес розподілу.
Кейс: як трекінг витримав розподіл на 180 тисяч адрес
Завдання було типовим для airdrop-кампанії: снапшот за кількома джерелами активності, розрахунок часток і розподіл токенів на 180 тисяч адрес.
Попередня спроба на скриптах і таблицях дала збій — частина адрес потрапила у вибірку двічі, частина випала через розбіжність у правилах між джерелами. Розбір помилок зайняв тижні, довіра учасників просіла.
Ми перезібрали контур: снапшот фіксується за єдиним правилом із журналом усіх вхідних даних, розрахунок часток іде детерміновано, а кожне нарахування отримує трасований ідентифікатор.
Спірний кейс тепер піднімається за цим ідентифікатором за хвилини — видно, які дані та яке правило дали результат.
Chainalysis у своїх розборах не раз показував, що саме прозорість розрахунку, а не розмір виплати, визначає, чи залишаться учасники в проєкті після розподілу.
Що змінилося за метриками. Час розрахунку снапшота скоротився з кількох діб ручної звірки до годин на тому самому обсязі адрес. Частка помилкових нарахувань упала з відсотків до часток відсотка — залишок закривається ручною перевіркою до відправлення транзакцій.
Розбір спірного кейсу стиснувся з днів до хвилин, бо інженер бачить весь ланцюжок розрахунку, а не відновлює його за логами.
Замовник підтвердив результат окремо: розподіл пройшов без зупинок, звернень до підтримки щодо нарахувань виявилося в рази менше очікуваного, а відкат за помилковими адресами виконали точково, не торкаючись решти.
Чим відрізняється снапшот за логами мережі від снапшота за внутрішньою базою?
Снапшот за логами мережі будується з подій, які емітить сам контракт: індексуємо логи в діапазоні блоків, зіставляємо адреси та суми, отримуємо стан на потрібній висоті.
Таке джерело первинне — воно не залежить від того, як наша система інтерпретувала транзакцію, і будь-який учасник може відтворити вибірку незалежно.
Зворотний бік — затримка: між відправленням транзакції та її потраплянням у підтверджений блок минає час, а при реорганізації ланцюжка частину подій доводиться перечитувати заново.
Снапшот за внутрішньою базою береться з уже зібраного індексу: таблиця балансів, історія операцій, агрегати за гаманцями. Він віддається миттєво і не потребує звернення до вузла, але його повнота обмежена тим, що встиг записати наш індексатор.
Якщо обробник пропустив подію або впав на середині діапазону, у базі залишиться діра — і снапшот буде формально валідним, але неправильним за складом.
Ключова відмінність — у вартості звірки. Логи мережі дорожчі на етапі читання, зате дешеві в перевірці: контрольна сума за діапазоном блоків сходиться в будь-якого незалежного учасника.
Внутрішня база дешева на читанні, але потребує окремого аудиту — звірки з першоджерелом, пошуку розбіжностей за адресами та розбору випадків, коли індекс і мережа розійшлися.
На практиці ми не вибираємо одне джерело, а будуємо їхню зв'язку: логи мережі — еталон і точка відновлення, внутрішня база — швидкий шар видачі для розрахунку часток.
Розбіжність між ними — сигнал, що індексатор відстав або втратив діапазон; тоді снапшот перезбирається з логів, а не «докручується» правками в базі. Це знімає головний ризик розподілу — тиху неповноту, через яку частина адрес не потрапляє до списку і отримує менше належного.
Технічні сумніви перед стартом робіт
Перед стартом майже завжди виринають одні й ті самі питання: що робити з уже розгорнутим трекінгом, як бути, якщо історія гаманців неповна, і як переконатися, що нарахування пройшло коректно. Нижче — розбір без загальних слів, з інженерною логікою.
У нас уже розгорнуто трекінг — переписувати все з нуля?
Ні. Спочатку знімаємо поточний стан: які події пишуться, у якому форматі, де губляться. Далі або надбудовуємо відсутні шари поверх наявного, або переносимо дані в нову схему зі збереженням історії.
Повний перезапуск виправданий лише якщо поточна модель не розрізняє типи активності й відновити її постфактум неможливо.
Що робити з частковими даними по гаманцях?
Часткові дані — норма, а не виняток: частина адрес з'явилася пізніше за снапшот, частина активностей не індексувалася. Ми позначаємо такі записи окремим статусом, а не відкидаємо, і рахуємо нарахування за явно заданими правилами дозаповнення.
Так розподіл залишається відтворюваним: за будь-якою позицією видно, які дані лягли в основу і чого не вистачало.
Як перевіряється коректність нарахування?
Нарахування звіряється з незалежним перерахунком за тими самими вхідними даними — розбіжність за будь-якою адресою виринає до розподілу, а не після.
Додатково фіксуємо контрольні суми за батчами та журнал змін: якщо правило змінювалося, видно, яка версія застосувалася до якої групи. Це дає можливість відкотити конкретний батч, не чіпаючи решту.
Як переноситься історія під час міграції даних?
Міграція йде зі збереженням вихідних ідентифікаторів і міток часу, щоб старі та нові записи не дублювалися під час повторної обробки. Перед перемиканням проганяємо паралельний розрахунок на старих і нових даних і порівнюємо результат — перехід вважається завершеним лише за збігу. Відкат можливий на будь-якому кроці, поки не зафіксовано фінальний снапшот.
Якщо ваш випадок не потрапляє в жоден із цих сценаріїв — опишіть задачу, повернемося з оцінкою та планом робіт.
Обговоримо ваше завдання трекінгу та розподілу
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібно зрозуміти вашу конфігурацію: де живе снапшот (власна мережа, EVM-сумісна або кілька), як формується список адрес, хто і на якій підставі ухвалює рішення про включення до розподілу.
Від цього залежить архітектура трекінгу: чи індексуємо ми події з блоків напряму, чи слухаємо мемпул для фіксації активності до включення в блок, чи будуємо гібридну схему з проміжним сховищем стану.
Окремо уточнимо правила розподілу: фіксовані частки, ваги за обсягом активності, пороги відсікання, обробка адрес-контрактів і мультисигів.
Тут найчастіше спливають розбіжності між тим, що задумано в токеноміці, і тим, що реально можна порахувати по ланцюжку — їх краще зняти до старту, а не на етапі роздачі.
До обговорення підготуємо:
- чернетку схеми індексації: які події та виклики контрактів потрапляють у трекінг, з якою глибиною зберігання;
- модель снапшоту: момент фіксації, обробка реорганізацій ланцюжка, ідемпотентність повторних запусків;
- правила розрахунку ваг і порогів — у вигляді, який можна перевірити на тестовому наборі адрес;
- прототип пайплайну розподілу з dry-run режимом: спочатку прогін на копії даних, потім реальні транзакції;
- політику доступу до ключів і ролей: хто ініціює роздачу, хто підтверджує, як влаштований аудит дій;
- план моніторингу: алерти на розбіжність суми до розподілу і фактично надісланого обсягу;
- попередню оцінку термінів за етапами — від постановки до першого тестового розподілу.
Опишіть завдання: мережа, обсяг адресатів, поточний спосіб обліку активності та що вже реалізовано. Повернемося з оцінкою, планом робіт і списком матеріалів, які знадобляться з вашого боку.
