Чому делегування голосів ламається в мобільному DAO
Делегування голосів у мобільному DAO-додатку ламається не на рівні логіки підрахунку, а на рівні доставки стану до пристрою. Користувач підписує транзакцію, інтерфейс показує нову вагу голосу, а мережа в цей момент ще не підтвердила операцію.
Далі будь-яка дія — повторне делегування, зміна делегата, відкликання — будується на хибній картині, і додаток упевнено веде людину в глухий кут.
Найчастіша причина — розсинхронізація стану між локальним кешем і ланцюгом. Мобільний клієнт тримає останній відомий знімок розподілу голосів, щоб список делегатів відкривався миттєво, і оновлює його за подіями.
Якщо додаток пішов у фон, втратив з'єднання або пропустив блок, знімок застаріває мовчки: інтерфейс малює старі ваги, а транзакція йде з уже неактуальними параметрами. Користувач бачить одне, мережа виконує інше.
Друга група збоїв — дублі та завислі транзакції. Подвійний тап по кнопці делегування, повторне надсилання після таймауту, перезапуск додатка в момент очікування підтвердження — і в мемпулі опиняються дві операції з однаковим наміром.
Одна проходить, друга висить або відхиляється, а баланс голосів в інтерфейсі розходиться з реальним. Окремо варто згадати застряглу транзакцію із заниженою комісією: вона не підтверджується, але й не зникає, блокуючи чергу наступних операцій за тим самим акаунтом.
Третє джерело — незбіг моменту підпису та моменту виконання. Між ними змінюється епоха голосування, спливає строк повноважень делегата або спрацьовує правило, що обмежує ланцюжок делегування. Транзакція формально валідна, але застосовується до стану, якого вже немає.
Розбираємо, як це закривається: ідемпотентні операції, явні стани очікування замість оптимістичного оновлення інтерфейсу та перезбирання знімка голосів із підтверджених подій, а не з локальних здогадок.
Що дає коректна реалізація делегування
Коректна реалізація делегування голосів впирається в три речі: як застосунок рахує вагу голосу на момент знімка блокчейну, як він показує користувачеві, кому і на який строк він передає право голосу, і як скасовує делегування без втрати вже врахованих голосів.
Якщо хоча б один шар реалізовано «на око», користувач бачить одне, мережа враховує інше — і першою це помічає не розробник, а підтримка.
Швидкість підтвердження операції визначається не самою транзакцією, а тим, що відбувається до неї.
Коли застосунок заздалегідь підвантажує актуальний список делегатів, кешує стан знімка і не ганяє користувача по трьох екранах заради одного підпису, підтвердження вкладається в одне очікування мережі замість кількох послідовних.
Різниця відчутна саме на слабкому мобільному інтернеті, де кожна зайва синхронізація — це хвилини і покинута операція.
Частка успішних операцій зростає, коли застосунок валідує делегування до відправки: перевіряє, що адреса делегата коректна, що строк не минув, що в користувача достатньо коштів на комісію, і що повторний підпис не створить дубль.
Відхилена мережею транзакція коштує користувачеві часу й довіри, а нам — звернення до підтримки, яке дорожче за будь-яку попередню перевірку на клієнті.
Зниження кількості звернень до підтримки — це прямий наслідок прозорості. Користувач має бачити, скільки голосів він делегував, на який строк і як повернути їх собі, не читаючи документацію.
Коли стан делегування відображається чесно й оновлюється само, питання «чому мій голос не врахували» і «як скасувати» просто перестають виникати.
Саме тому підтримка делегування — це не одна кнопка, а зв'язка з розрахунку ваги, відображення стану і відкату. Розбираємо, як це влаштовано в мобільному застосунку і що перевіряємо перед релізом.
Способи обліку голосів: порівняння підходів
Облік голосів у мобільному DAO — це не одна механіка, а розвилка з кількох моделей, і вибір між ними визначає, як застосунок поводитиметься при зростанні кількості учасників. Нижче — робочі варіанти, які ми реалізовували, з чесними обмеженнями кожного.
| Варіант обліку | Коли підходить | Обмеження |
|---|---|---|
| Пряме делегування за адресою | Невелика спільнота, голосувальна база стабільна, важлива простота | При зростанні кількості делегатів дорожчає перерахунок ваг; ручне перепризначення при зміні гаманця |
| Делегування за кампаніями | Голосування йдуть хвилями, у кожного — свій склад учасників | Потрібна окрема логіка снепшотів на кожну кампанію; складніший аудит історії |
| Суб-делегування (ланцюжки) | Великі структури з представниками та підпредставниками | Ризик зациклення ланцюжків; потрібен контроль глибини та захист від петель |
| Гібрид: пряме + пул | Частину голосів тримають самі, частину віддають у спільний пул | Подвійний облік при неакуратному снепшоті; прозорість потребує окремого екрана |
Пряме делегування за адресою — найпередбачуваніший варіант: користувач призначає делегата, вага перераховується при кожному голосуванні. Обмеження проявляється на масштабі — чим більше зв'язків, тим дорожчий і довший перерахунок, а зміна гаманця потребує ручного перепризначення.
Делегування за кампаніями знімає частину цього навантаження: голоси прив'язуються до конкретного голосування, а не до акаунта назавжди.
Натомість з'являється вимога до снепшотів — стан ваг потрібно фіксувати на момент старту кампанії, інакше підсумки «попливуть» при пізніх делегуваннях.
Суб-делегування дає гнучкість великим структурам, але потребує захисту від ланцюжків-петель і обмеження глибини.
Гібридна модель зручна для змішаних спільнот, однак подвійний облік — найчастіша помилка: без чіткого розділення прямих і пулових голосів на етапі снепшота підсумки розходяться з очікуваннями.
На практиці вибір зводиться до трьох питань: скільки делегатів очікується, як часто змінюється їхній склад і чи потрібна історія для аудиту. Відповіді на них і визначають, який варіант обліку голосів ляже в основу застосунку без переробок на наступному етапі зростання.
Як ми впроваджуємо модуль делегування голосів
Впровадження модуля делегування голосів починається з аудиту: дивимося, як у застосунку влаштовані облікові записи, де зберігаються ключі підпису, які мережі та контракти вже підключені.
На цьому етапі важливо зрозуміти, чи голосує користувач сам або делегує право іншій адресі, і як це відображається в історії. Без такої перевірки модуль легко спроєктувати так, що він конфліктуватиме з наявною логікою гаманця.
Далі вибудовуємо схему делегування: хто може бути делегатом, на який строк, чи можна відкликати право достроково і що відбувається при повторному делегуванні.
Окремо опрацьовуємо сценарії, коли делегат втрачає доступ або сам відмовляється від голосів — такі випадки найчастіше ламають голосування в реальних спільнотах.
- Аудит поточного застосунку — розбираємо облікові записи, зберігання ключів, підключені мережі та контракти, фіксуємо обмеження.
- Проєктування схеми делегування — визначаємо ролі, строки, правила відкликання та повторної передачі голосів.
- Налаштування модуля — підключаємо логіку до гаманця та контрактів, налаштовуємо підпис операцій делегування.
- Перевірка сценаріїв — проганяємо передачу, відкликання, повторне делегування та голосування від імені делегата.
- Тестування на тестовій мережі — перевіряємо поведінку модуля без ризику для реальних голосів і активів.
- Передача та документація — описуємо схему, правила та порядок дій для команди підтримки.
Кожен етап закінчується перевіркою: якщо сценарій відкликання або повторного делегування відпрацьовує невірно, повертаємося до схеми, а не латаємо поведінку на рівні інтерфейсу. Так модуль залишається передбачуваним і при зростанні числа учасників, і при зміні делегатів.
На виході замовник отримує працюючий модуль делегування голосів, схему його взаємодії з гаманцем і контрактами, а також документацію для підтримки. Опишіть вашу задачу — повернемося з оцінкою та планом етапів.
Що замовник отримує на руки
Передаємо не «працюючий код», а комплект, за яким модуль делегування голосів живе та розвивається без нас. Кожен артефакт закриває свій клас питань: як влаштовано, як перевірити, як змінювати та що робити при збої.
- Конфігурації модуля делегування — параметри мережі, адреси контрактів, пороги ваги голосу та правила перерахунку при зміні делегата. Винесені в окремі файли середовищ, щоб перемикання між тестовим і робочим контуром не вимагало правок коду.
- Схеми потоків голосів — як голос іде від власника до делегата, де фіксується снапшот, у який момент вага перестає враховуватися при відкликанні. Схема знімає половину питань на дзвінках з юристами та аудиторами.
- Політики доступу та ролей — хто з адміністраторів може змінювати параметри делегування, хто лише читає, як видаються та відкликаються права. З матрицею ролей і журналом дій.
- Документація з інтеграції — опис методів, форматів запитів і відповідей, кодів помилок. Достатньо, щоб стороння команда підключила модуль, не читаючи вихідний код.
- Регламенти експлуатації — що робити при розбіжності ваги голосу, як відкотити невдалу зміну параметрів, куди дивитися в першу чергу. З чек-листом для чергового.
- Набір перевірок — тести на сценарії делегування та відкликання, включно з граничними: делегат пішов, вага змінилася між голосуваннями, подвійне делегування.
- Запис передачі — розбір архітектурних рішень і відкритих питань, щоб контекст не залишився лише в листуванні.
Комплект зібрано так, що новий інженер входить у модуль за документацією, а не за усними поясненнями. Опишіть задачу — повернемося з оцінкою та планом по вашому контуру.
Кейс: прискорення делегування в мобільному гаманці
Клієнт — команда мобільного DAO-гаманця на NEAR — звернувся зі скаргою: делегування голосів працювало, але користувачі доходили до нього рідко.
Операція займала 6 екранів і 4 підтвердження, середній час проходження — 3 хвилини 40 секунд, а частка покинутих на середині спроб трималася на 38%. Підтримка отримувала по 40-60 звернень на тиждень, і майже всі — «не розумію, кому делегую» та «голос пішов не туди».
Що змінили
Переписали потік на один екран: вибір делегата, розмір частки та підтвердження — в одному поданні з живим перерахунком ваги голосу.
Додали попередній перегляд наслідків до підпису, кеш списку делегатів із фоновим оновленням і явний статус операції після відправлення — замість екрана очікування з невизначеним результатом.
Окремо закрили клас помилок, який давав найбільше шуму: невідповідність обраного делегата та фактично підписаної транзакції. Тепер параметри делегування збираються в одному місці й перевіряються перед підписом, а не по дорозі через кілька екранів.
Що стало
Середній час операції впав до 50 секунд, частка покинутих спроб — до 9%. Звернення до підтримки щодо делегування скоротилися вчетверо, а повторні делегування (зміна делегата) зросли втричі — люди почали користуватися функцією, а не пробувати її один раз.
Навантаження на мережу при цьому не зросло: кількість транзакцій на користувача залишилася незмінною, змінилося лише те, скільки з них доходять до підпису.
Чим відрізняється пряме делегування від ланцюжка?
Пряме делегування — це один зв'язок: власник токенів призначає делегата, і вага його голосу повністю переходить цій адресі. Ланцюжок виникає, коли делегат сам комусь делегує свою сукупну вагу, і голос продовжує рух далі за графом.
Різниця не косметична: вона визначає, як застосунок рахує підсумкову вагу на момент голосування і що відбувається при відкликанні.
При прямому варіанті облік голосів тривіальний — вага того, хто голосує, дорівнює сумі делегованих йому токенів плюс власний баланс. Перерахунок локальний, стан сходиться за один прохід, а відкликання делегування миттєво повертає вагу власнику.
Ланцюжок вимагає обходу графа до кінцевих адрес: потрібно знайти всіх, хто фактично голосує, і підсумувати вагу за шляхами.
Тут з'являються два інженерні ризики — зациклення (A делегує B, B делегує A) і «зависла» вага, коли проміжний вузол відкликав делегування вже після початку голосування.
На практиці це впливає на три речі. Перша — момент фіксації ваги: знімок стану до старту голосування виключає маніпуляції з перекладанням голосів за ланцюжком. Друга — ліміт глибини: обмеження в 3-5 переходів захищає від нескінченного обходу і робить розрахунок передбачуваним.
Третя — обробка циклів: вузол, що потрапив у кільце, виключається з підрахунку, інакше транзакція голосування не завершиться.
Для замовника вибір зводиться до моделі управління. Пряме делегування простіше в аудиті й зрозуміліше учасникам, але не підтримує «делегата делегатів».
Ланцюжок дає гнучкість великим власникам і представникам спільноти, але вимагає явної логіки обходу, захисту від циклів і прозорого відображення в інтерфейсі — хто за ким стоїть і куди пішла вага.
В обох випадках облік голосів має бути детермінованим: однаковий результат при перерахунку на будь-якому вузлі мережі.
Часті технічні сумніви
Делегування голосів — механіка, де помилка в правах доступу коштує найдорожче: скомпрометований ключ делегата виводить вагу голосів, а незворотна транзакція в основній мережі не відкочується.
Тому питання безпеки, сумісності та відкату розбираємо до старту розробки, а не після першого інциденту.
Як захищені ключі та підписи під час делегування?
Приватний ключ не залишає захищений контур пристрою: підпис формується в апаратному сховищі (Secure Enclave / Keystore), застосунок отримує лише результат.
Делегат задається за адресою, ліміти за вагою та строком прописуються в самому виклику контракту — навіть у разі компрометації сесії зловмисник не виведе більше, ніж дозволено. Додатково логуємо кожну дію та надсилаємо пуш при зміні делегата.
Чи сумісно з уже розгорнутими контрактами та гаманцями?
Так, якщо контракт підтримує стандартний інтерфейс делегування. Ми перевіряємо сигнатури методів, типи значень, що повертаються, та поведінку при повторному виклику, потім проганяємо сценарії на тестовій мережі з реальними адресами.
Для гаманців, де немає нативної підтримки, додаємо шар-адаптер — користувач бачить звичний екран підтвердження.
Що відбувається при відкаті транзакції?
У блокчейні відкат — це не «скасування», а нова транзакція зі зворотною дією. Ми проєктуємо делегування ідемпотентним: повторний виклик з тими самими параметрами не дублює вагу, а відкликання повертає голоси власнику.
Якщо транзакція не пройшла за газом або ревертом — стан не змінюється, застосунок показує зрозумілу причину та пропонує повторити.
Як перевіряємо коректність перед релізом?
Покриваємо контракт і клієнт автотестами на сценарії: делегування, відкликання, повторне делегування, граничні значення ваги та строку. Окремо — перевірка на витік ключів і на поведінку при обриві мережі. Реліз іде через аудит контракту та поступове включення на частці користувачів.
Обговоримо ваше завдання щодо делегування голосів
Делегування голосів — механіка, де помилка в конфігурації коштує дорожче, ніж у звичайному екрані: неправильно порахована вага голосу або втрачений стан делегата спотворюють результат голосування, а відкотити його постфактум неможливо.
Тому перед стартом ми розбираємо модель делегування до деталей — хто кому передає голос, як рахуються ланцюжки, що відбувається при відкликанні та як поводиться інтерфейс при розсинхронізації з мережею.
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібно зрозуміти ваше завдання щодо делегування голосів предметно. Опишіть сценарії та обмеження — цього достатньо, щоб оцінити обсяг і запропонувати архітектуру.
- Поточна модель делегування: пряма передача голосу, ланцюжки делегатів або гібрид із частковою вагою.
- Мережа та стандарт: де живе облік голосів, як застосунок читає стан і підтверджує транзакції.
- Гаманець і підписи: які способи підключення підтримуються, чи потрібна підтримка апаратних гаманців.
- Сценарії відкликання та перерозподілу: як голос повертається делегату і що бачить користувач у цей момент.
- Офлайн-поведінка: що показуємо при втраті зв'язку і як синхронізуємо стан при поверненні.
- Наявний код: чи є прототип або застосунок, який потрібно доопрацювати, а не писати з нуля.
- Обмеження за термінами та платформами: iOS, Android чи обидві, чи потрібна синхронність релізів.
За підсумками розбору ми повертаємося з оцінкою термінів, планом етапів і списком ризиків — що робимо першим, де закладаємо запас на інтеграцію з мережею і як перевіряємо коректність підрахунку голосів до релізу. Опишіть завдання — обговоримо деталі та запропонуємо рішення під ваш сценарій делегування.
