Розподілене управління
(Розділ: Екосистема та Мережа)
1) Навіщо розподілене управління
Розподілене управління (governance) формалізує прийняття рішень в мережі без єдиного центру: правила змінюються передбачувано, бюджети розподіляються прозоро, ризики контролюються, а учасники (оператори, провайдери, студії, валідатори/ноди, афіліати, ком'юніті, дослідники) отримують реальний голос і відповідальність. Це зменшує регуляторні та операційні ризики, знижує конфліктність і прискорює еволюцію протоколів.
2) Ролі та органи управління
Асамблея учасників (General Assembly) - всі власники права голосу (токени/репутація/членство).
Делегати/представники - обрані мандати з відкликанням; агрегують голос дрібних учасників.
Рада протоколу (Protocol Council) - обмежений мандат на технічні зміни та аварійні заходи (з time-lock і вето-правом асамблеї).
Казначейство (Treasury Committee) - відповідає за бюджети/гранти, але кожне виділення проходить он-чейн/офчейн затвердження за регламентом.
Комітет з ризиків - моніторинг параметрів мережі, ліміти, паузи (circuit breaker), рекомендації з оновлень.
Арбітраж/апеляції - незалежна процедура вирішення спорів, включаючи on-chain докази і оффчейн аудит.
Секретаріат/DevRel - операційний супровід: публікація повістки, збір коментарів, звітність.
3) Моделі голосування та розподілу впливу
1 токен = 1 голос - проста, але вразлива до концентрації.
Делеговане голосування (liquid democracy) - гнучкість і масштабованість.
Квадратичне голосування (Quadratic) - знижує домінування великих холдерів, коштує дорожче «купити» великі частки впливу.
Conviction voting - голос «накопичується» з часом, стимулюючи стійкі переваги.
Ф'ютархи (Futarchy) - рішення через ринки передбачень (для експериментальних параметрів).
Багато-палатність - техпалата (валідатори) + призначена для користувача палата (оператори/студії) + партнерська (провайдери); рішення вважається прийнятим при проходженні всіх палат (або 2 з 3).
- Мінімальний кворум (наприклад, ≥ 10-20% активованої ваги).
- Поріг прийняття: проста більшість для операційки, супербільшинство (≥ 66% або ≥ 75%) - для змін безпеки/емісії/прав доступу.
- Time-lock на виконання (48-168 годин) + veto/оборотний timelock порадою протоколу при SEV-ризиках.
4) Життєвий цикл пропозиції (Proposal Lifecycle)
1. Ідея (RFD/RFC) - текст, обґрунтування, ризики, альтернативи, метрики успіху.
2. Пре-ревью - формальна перевірка на відповідність шаблону/юрисдикціям/безпеки.
3. Тестова стадія - A/B, симуляції, пілоти, тест-ні/стейджинг.
4. Голосування - он-чейн Snapshot/он-чейн контракт, офчейн репутація допустима як додатковий сигнал.
5. Timelock - вікно для апеляцій/аудиту.
6. Виконання - on-chain транзакції мультисигом/контрактом виконавця, офчейн накази і регламенти.
7. Post-mortem/ретроспектива - оцінка KPI, ревізія ризиків, коригування регламентів.
- Мета, область впливу, зміни параметрів/бюджетів, ризики/контроль, метрики успіху, оборотність (rollback), план комунікацій, юридичні застереження.
5) Cross-chain і міжмережеве управління
Мости управління: «governance relayers/оракули» передають результат голосування між ланцюгами/домейнами.
Модель джерела істини: одна «батьківська» мережа приймає рішення, залежні мережі підписують і виконують (light-client/меркл-докази).
Анти-ризик: фіналізація із затримкою, кворум для міжчіпних змін вище, ніж внутрішньомережевий, дублюючий вето-механізм.
Ізоляція відмов: якщо міст/домен скомпрометований - локальний «circuit-breaker» і ручна синхронізація за регламентом.
6) Казначейство, бюджети та гранти
Казначейський мультисиг/смарт-казначейство: ліміти на транзакції, списки дозволених категорій, time-lock.
Планування: квартальні/річні бюджети, резерви на інциденти (SEV-фонд), грантові програми (R&D, DevRel, безпека, локалізація).
Прозорість: публічні звіти, дешборди витрат, KPI грантів (випуск, імпакт, адопшен).
Аудит: внутрішній (комітет) + зовнішній (незалежні аудитори), ревізія кожне півріччя.
7) Безпека і анти-захоплення
Anti-Sybil: перевірка ідентичностей (KYB/KYC для організацій), репутаційні ліміти, багатофакторні критерії ваги (токени + активність/внесок).
Захист від підкупу/хабарів: коміт-розкриття (commit-reveal), приватне голосування, сліпі підписи.
Flash-loan атаки: снапшот балансів за часом, lock-up для участі, time-weighted voting.
Veto/Guardian: обмежений за мандатом і часом «стоп-кран», підконтрольний асамблеї.
Rate-limit змін: «одна велика зміна параметрів → одне голосування», кулдаун між голосуваннями.
Межі повноважень: список «неможливих дій» (non-upgradable core, незмінні інваріанти).
8) Прозорість і спостережуваність governance
Публічний реєстр пропозицій, статусів, аргументів «за/проти», зв'язку з ризиками і дашбордами.
Трасування: кожна он-чейн операція пов'язана з конкретним proposal-ID.
Архів комунікацій: стенограми обговорень, відповіді на RFD.
Локалізація та інклюзивність: резюме на основних мовах екосистеми, SLA відповіді на питання ком'юніті.
9) Метрики управління (KPI/SLO)
Участь і представництво
VPR (Voter Participation Rate) = Проголосував вага/Загальний активований вага.
Диверсифікація впливу (Gini/Herfindahl) - концентрація голосів.
Частка делегування і середня «глибина делегацій».
Time-to-Deliberation - медіана часу від RFD до голосування.
Якість рішень
Adoption Rate - частка прийнятих рішень, реалізованих вчасно.
Rollback Rate - частка рішень, скасованих або відкатаних.
Impact Score - приріст ключових продуктових/мережевих KPI після виконання.
Prediction Accuracy (для ф'ютархи) - точність ринків vs фактичні метрики.
Операційка
SLA публікації повістки/протоколів (наприклад, ≤ 24 ч).
Compliance Coverage - частка рішень з юр. експертизою/оцінкою ризиків.
Audit Latency - час від виконання до аудиторського звіту.
10) Регламенти та SLO
Регламент кворуму та порогів: різні класи змін → різні пороги.
SLO комунікацій: відповіді модераторів ≤ 48 год; фінальна версія повістки ≥ 72 год до голосування.
SLO безпеки: timelock ≥ 48–168 ч; emergency-pause ≤ 15 хв від детекту SEV-1; публічний звіт ≤ 72 год.
SLO прозорості: публікація звітів казначейства щомісяця; реєстр грантів - у реальному часі.
11) Юридичні та комплаєнс-аспекти
KYB/KYC шари: для впливаючих рішень - верифікація організацій і відповідальних осіб.
Data residency/PII: зберігання і публікація даних в рамках юрисдикцій; анонімізація протоколів голосувань при необхідності.
Конфлікт інтересів: декларації, заборона голосувати з «афілійованих» питань без розкриття.
Ліцензування/регулятори: відображення критичних змін (наприклад, фінансових параметрів) відповідно до локальних вимог.
12) Інциденти та аварійні процедури
Emergency-pause (частковий/повний): зупиняє небезпечні операції; активується радою протоколу з подальшим пост-фактум голосуванням.
Rollback/Hotfix: заздалегідь підготовлені «безпечні» стани, підписані мультисигом.
Комунікації: шаблон повідомлень (що трапилося, вплив, дії, ETA на нормалізацію).
Пост-мортем: обов'язковий, публічний, з планом запобігання повторення.
13) Технічні патерни реалізації
Governance-контракти: реєстр пропозицій, кворум/поріг, timelock, роль guardian/veto, модуль казначейства, модуль параметрів протоколу.
Снапшоти: фіксація прав голосу по висоті блоку/часу.
Мультисиг з рольовою моделлю: казначейство, emergency, апгрейди (N-of-M, різні M для різних класів дій).
Оракули/релеї: підтверджують кворум/результат між доменами.
Логи та підписи: незмінні журнали, зв'язність з proposal-ID.
14) Приклад мінімальної схеми даних (псевдо-SQL)
sql
-- Offer Register
CREATE TABLE gov_proposals (
id TEXT PRIMARY KEY,
title TEXT, author TEXT, created_at TIMESTAMPTZ,
class TEXT, -- class: param, budget, security, protocol_update...
status TEXT, -- draft active queued executed rejected rolled_back quorum_req NUMERIC, threshold_req NUMERIC,
timelock_until TIMESTAMPTZ,
metadata JSONB -- links, risk, legal, locales
);
-- Voices
CREATE TABLE gov_votes (
proposal_id TEXT REFERENCES gov_proposals(id),
voter TEXT, -- address/peer-id/org-id weight NUMERIC, -- snapshot-weight choice TEXT, -- for against abstain committed_at TIMESTAMPTZ,
PRIMARY KEY (proposal_id, voter)
);
-- Execution/Transaction
CREATE TABLE gov_exec (
proposal_id TEXT REFERENCES gov_proposals(id),
tx_hash TEXT, executed_at TIMESTAMPTZ, executor TEXT,
result TEXT, logs JSONB
);15) Приклад політики (псевдо-YAML)
yaml governance:
classes:
param_change:
quorum: 0. 10 threshold: 0. 50 timelock_hours: 72 security_critical:
quorum: 0. 20 threshold: 0. 66 timelock_hours: 168 guardian_veto: true treasury_grant:
quorum: 0. 12 threshold: 0. 55 timelock_hours: 96 delegation:
enabled: true max_chain_depth: 2 anti_capture:
snapshot_delay_hours: 24 time_weighted: true private_ballots: true flashloan_protection: true emergency:
pause_enabled: true pause_slo_minutes: 15 rollback_playbook: "doc://rollback_v1"
transparency:
public_registry: true monthly_treasury_reports: true16) Дашборди та операційні огляди
Governance Health (щомісяця): VPR, диверсифікація впливу, частка делегування, середнє TTD (time-to-decision), частка виконаних без відкатів, активність по класах.
Treasury & Grants: burn-rate, залишки по фондах, CPA грантів (вартість/одиниця імпакту), термін від заявки до виплати.
Risk & Compliance: частка рішень з виконаним юр-чеком, інциденти безпеки, використання emergency-механік.
17) Чек-лист впровадження
1. Визначте класи рішень і відповідні пороги/кворуми/timelock.
2. Виберіть модель голосування (делегування + квадратичне/вага по репутації для грантів).
3. Розгорніть реєстр пропозицій, снапшоти та мультисиг-казначейство.
4. Затвердіть playbook інцидентів і emergency-процедури.
5. Налаштуйте дашборди прозорості та щомісячні звіти казначейства.
6. Запустіть пілотний цикл (RFD→golosovaniye→ispolneniye→retro), зберіть фідбек.
7. Щоквартально ревізуйте пороги, ролі, безпеку та юридичні застереження.
18) Глосарій
Кворум - мінімальна сумарна вага голосів для легітимності рішення.
Поріг (threshold) - частка голосів «за» для прийняття.
Timelock - затримка перед виконанням рішення.
Guardian/Veto - обмежений механізм екстреного блокування.
Snapshot - фіксація прав голосу в часі.
Delegation - передача права голосу представнику.
Quadratic/Conviction voting - механіки зниження монополії великих стейків/посилення довгострокових переваг.
Futarchy - прийняття рішень на основі ринків передбачень.
Підсумок: розподілене управління перетворює екосистему в передбачуваний і стійкий «організм», де рішення приймаються прозоро, ризики контролюються заздалегідь, бюджети витрачаються за правилами, а еволюція мережі йде ітеративно і безпечно. Правильна комбінація моделей голосування, порогів, timelock, анти-захватних механізмів і строгих операційних регламентів робить управління не формальністю, а робочим інструментом зростання.