Polkadot використовує складний механізм управління, який може елегантно еволюціонувати відповідно до потреб зацікавлених сторін. Його мета – забезпечити, щоб більшість прав завжди контролювала мережу.
Цей зміст може змінюватися. Протокол управління вже пройшов кілька ітерацій (v1 та v2), у майбутньому буде ще більше змін (v2.5).
Першою децентралізованою системою управління Polkadot (v1) є три основні компоненти:
Технічний комітет: управління графіком оновлення
Рада: виконавчий "уряд", обраний шляхом виборів, відповідальний за управління параметрами, управління та витратами пропозицій
Референдум: загальне голосування з усіх інших питань, зацікавлені сторони з довгостроковими інтересами мають більший вплив
Ця система на початковому етапі працювала добре, допомагаючи раціонально використовувати бюджетні кошти та своєчасно виконувати оновлення та ремонти. Але з розвитком системи потрібно постійно вдосконалювати недоліки та слідкувати за прогресом. Наприклад, у "управлінні v1" всі голоси на референдумі мають однакову вагу, і можна голосувати лише за один референдум за раз, при цьому період голосування може тривати кілька тижнів. Це призводить до того, що система схильна ретельно розглядати лише дуже незначну кількість пропозицій, а не широко розглядати кілька пропозицій. Тому з'явилася "управління v2".
"治理v2" або "Gov2" змінив спосіб щоденного прийняття рішень, зробивши голосування більш впливовим і швидким, що значно збільшило кількість колективних рішень, які може приймати система.
Після остаточної професійної перевірки коду Gov2 запуститься на Kusama. Після тестування на Kusama буде подано пропозицію щодо його розгортання на Polkadot.
Далі буде представлено основні принципи управління мережею Polkadot. Розуміння витоків управління v1 допоможе краще зрозуміти напрямок другого ітераційного процесу. Ці відмінності та розбіжності будуть підкреслені в різних підтемах.
Слід зазначити, що на даному етапі управління все ще є протоколом, що постійно розвивається. З оновленням управління v2 в мережу також розробляється план управління v2.5.
передумова
Підсумовуючи, ця мережа об'єднує кілька новаторських механізмів, включаючи функції перетворення станів без фіксованого типу, що зберігаються в ланцюзі і визначаються WebAssembly, а також кілька механізмів голосування в ланцюзі, таких як референдум з адаптивним абсолютним більшістю порогу та механізмом голосування за груповим схваленням.
Усі зміни до угоди повинні бути погоджені шляхом голосування з урахуванням прав власності.
механізм
У治理v1 активні власники токенів та рада спільно управляють рішеннями щодо оновлення мережі. Незалежно від того, чи пропозицію вносять публічні ( власники токенів ), чи рада, остаточне рішення має бути ухвалене шляхом загального голосування серед усіх власників, з урахуванням ваги за сумою застави та значенням віри.
У治理v2 є кілька змін. Новий режим управління відображає особливості децентралізації таким чином:
Передача всіх обов'язків ради через демократичне голосування токенам, які їх утримують
Розпустити чинний колегіальний правління
Дозволити користувачам делегувати свої голоси членам громади більшою кількістю способів
У Раді Gov1 виконуються ролі представника пасивних власників токенів, охоронця скарбниці та ініціатора законодавства, але зазвичай їх вважають централізованими сутностями. Для подальшої децентралізації мережі Gov2 пропонує повернути обов'язки Ради до громади.
референдум
Референдум - це простий, інклюзивний, заснований на стейкінгу механізм голосування. Кожен референдум має конкретну пропозицію, яка реалізується за допомогою виклику функцій привілеїв runtime у формі (, включаючи найпотужніший виклик set_code, який може переключити весь код runtime ).
Референдум є дискретною подією з фіксованим терміном голосування. Після закінчення терміну голосування та підрахунку голосів, у разі схвалення буде викликано відповідну функцію. Референдум завжди є бінарним; вибір може бути лише "за", "проти" або повна відмова.
У версії управління v1, референдум може бути розпочато одним із таких способів:
Публічно подані пропозиції
Пропозиція, схвалена більшістю голосів або одноголосно
Пропозиція, подана в рамках виконання попереднього референдуму
Термінова пропозиція, подана технічним комітетом та затверджена правлінням.
Усі референдуми мають відповідний період затримки виконання. Це проміжок часу між закінченням референдуму та фактичним виконанням пропозиції (, якщо вона була схвалена ).
Якщо референдум закритий і підрахунок завершено, він вважається завершеним. Якщо пропозицію затверджено, її буде заплановано для виконання. Якщо референдум чекає на результати, тобто триває голосування, він вважається незавершеним.
Якщо пропозиція подана громадськістю або радою, то існує фіксований термін виконання 28 днів. Пропозиції, подані в рамках виконання попередніх референдумів, можуть мати встановлений термін виконання за потреби. Обробка термінових пропозицій вимагає "швидкого реагування" на суттєві питання, що скорочує терміни виконання.
У Gov2 будь-хто може в будь-який час розпочати голосування та ініціювати багаторазові голосування. Gov2 запроваджує нові функції Origins( джерел) та Tracks( треків) для полегшення процесу та обробки голосувальних протоколів.
Origin може вважатися багатим дескриптором для заданого рівня привілеїв. Тепер пропоненту потрібно вибрати відповідний Origin для запиту відповідно до вимог пропозиції.
Кожен Origin асоціюється з категорією референдуму, а кожна категорія асоціюється з треком. Трек описує життєвий цикл пропозиції та є незалежним від треків інших категорій. Наявність різних незалежних треків дозволяє мережі налаштовувати динаміку референдуму відповідно до прихованих рівнів привілеїв.
Наприклад, вплив оновлення Runtime ( на екосистему при виклику set_code ) відрізняється від схвалення бюджетних чайових ( при виклику reportAwesome ), тому потрібні різні Origins, де різні ставки голосування, ставки затвердження, депозити та найменший період виконання будуть попередньо визначені в pallet.
Пропозиція референдуму
Громадське голосування
Будь-хто може запропонувати референдум, внесши мінімальну кількість токенів протягом певного періоду ( блоків ). Якщо хтось погодиться з цією пропозицією, вони можуть внести таку ж кількість токенів для вираження підтримки.
Ця операція називається "підпис". Пропозиція, що отримала найбільшу підтримку токенів, буде обрана для наступного голосування. Зверніть увагу, що це може відрізнятися від абсолютної кількості підписок; наприклад, три рахунки, які кожен закріпили по 20 DOT, "перевершать" ефективність десяти рахунків, які кожен закріпили по 1 DOT.
Як тільки пропозиція буде подана (, розпочнеться голосування ), пов'язані токени будуть звільнені.
Управління v1 може мати до 100 громадських пропозицій у черзі пропозицій.
У Gov2, коли референдум створюється, спільнота може відразу проголосувати за нього. Але цей референдум не перебуває в стані, в якому можна завершити або підрахувати голоси, затвердити та врешті-решт виконати. Натомість, референдум повинен відповідати певним критеріям, щоб перейти в стан "вирішення (Deciding)". Перед входженням у цей стан він залишається в стані невизначеності.
Стандарти для переходу в стан Decided такі:
Переживши період введення ( lead-in period ), це час, який потрібно пройти перед прийняттям рішення. Це допомагає зменшити ймовірність "рішення на атаці", тобто атака з боку зловмисника, який контролює велику частину голосування, може негайно пройти пропозицію після її висунення, а не дати всім виборцям достатньо часу для розгляду та участі.
Обов'язково має бути залишковий простір для рішень. Усі треки мають обмеження на кількість референдумів, які можуть бути прийняті одночасно. Трек з більшою потужністю має нижчі обмеження. Наприклад, обмеження для рівня Root Origin становить 1, тобто одночасно можна прийняти лише 1 надзвичайно небезпечну пропозицію.
Необхідно сплатити депозит на рішення. Вартість створення референдуму дуже низька, оскільки вартість депозиту містить лише вартість зберігання в ланцюгу, необхідну для відстеження. Але при перевірці та ухваленні рішення щодо референдуму існує ризик виснаження обмежених місць у черзі референдумів. Вимога надання більшого, але повернутого депозиту допомагає зменшити спам.
Громадське голосування (v1)
Рада одноголосно проголосувала - коли всі члени ради погоджуються з пропозицією, її можна винести на голосування. Це голосування призведе до негативного відхилення голосування (, тобто чим менше голосів за, тим менше потрібно для прийняття - див. адаптивні групові упередження ).
Більшість ради проголосувала - коли лише проста більшість членів ради погоджується, можна також голосувати за референдум, але це буде система більшості, де переможе сторона, яка отримає 51% голосів (.
В будь-який момент може бути тільки один дійсний референдум, якщо тільки немає ще одного термінового референдуму.
Графік голосування
У Governance v1, якщо в одному з черг є принаймні одна пропозиція, нове голосування відбуватиметься кожні 28 днів. Пропозиції, затверджені радою, мають свою чергу, а пропозиції, подані громадськістю, також мають свою чергу. Голосування буде чергуватися між пропозиціями, що займають перші місця в обох чергах.
Найбільш пріоритетна пропозиція визначається кількістю стейків, які пов'язані з нею. Якщо поточна черга намагається створити референдум без пропозицій ) черга пуста (, і в іншій черзі є пропозиції в черзі, то найпершою пропозицією з іншої черги буде проведено референдум.
Не можна голосувати за декілька референдумів одночасно, за винятком термінових референдумів. Термінові референдуми, які відбуваються одночасно з звичайними референдумами ), що проводяться публічно або за пропозицією ради (, є єдиною ситуацією, коли можна голосувати за декілька референдумів одночасно.
Коли пропозиція буде схвалена, управління v2 матиме однаковий 28-денний період кваліфікації. Якщо на завершення цього етапу пропозиція все ще не буде схвалена, вона буде автоматично відхилена.
Голосування на референдумі ) управління v2(
У Governance v2, якщо пропозиція відповідає вимогам щодо рівня схвалення і підтримки, ця пропозиція буде затверджена, тобто було видалено адаптивну систему групових упереджень.
Ставка схвалення ) визначається як вага голосів за схвалення ( після коректування переконаності ) у загальному вазі голосів (, що включає частки схвалення та відхилення ).
Підтримка ( Support ) є загальною кількістю голосів, затверджених ( ігноруючи корекції переконання ) в порівнянні з загальною кількістю голосів, які можуть бути здійснені в системі.
Це повинно бути виконано в найкоротший термін підтвердження. Різні траєкторії мають різні терміни підтвердження та вимоги до схвалення та підтримки. Тепер можна налаштувати через необхідну кількість підтримки та загальне схвалення. Для пропозицій, що використовують джерела з нижчими привілеями, зниження необхідного відсотка голосування до більш реалістичної цифри є більш доцільним у порівнянні з пропозиціями, що використовують категорії з вищими привілеями (, такими як Root). Пропозиції, які мають велике політичне значення, можуть раніше вимагати вищого схвалення, щоб уникнути суперечок.
У Gov2, пропозиції, які не були схвалені протягом 28 днів, вважаються автоматично відхиленими, і Decision Deposit буде повернуто. Якщо пропозиція зможе залишитися затвердженою до закінчення періоду підтвердження, вона вважається схваленою і планується виконати її з джерела пропозиції після періоду розробки. Період розробки визначається під час голосування всього населення, але також підлягає мінімуму, заснованому на треках. Потужніші треки будуть примушувати до довшого періоду виконання, щоб забезпечити мережу достатнім часом для підготовки до будь-яких змін, які пропозиція може принести.
Добровільне блокування
Polkadot використовує концепцію "добровільного блокування", що дозволяє власникам токенів збільшувати свої голосувальні права шляхом заявлення про готовність заблокувати токени на певний термін. Таким чином, кількість голосів для кожного власника токенів буде обчислюватися за наступною формулою:
Кількість голосів = токен * множник переконання
Кількість термінів блокування подвоюється, множник переконання збільшить множник голосування на одиницю.
Максимальна кількість налаштувань "подвоєння" терміна блокування встановлена на 6(, отже, всього 32 терміни блокування ), один термін блокування дорівнює 28 дням. Дозволено лише подвоєння, наприклад, ви не можете заблокувати 24 періоди і збільшити вашу переконаність на 5.5.
після блокування токена ви все ще можете використовувати його для голосування та стейкінгу; вам заборонено лише переводити ці токени на інший рахунок.
Голосування завжди "обчислюється" в один і той же час, тобто по закінченні періоду голосування. Це не підлягає впливу терміну блокування токенів.
Адаптивні групові упередження
Адаптивне групове відхилення використовувалося в Governance v2 довше і було замінене системою Approval/Support.
( Рада
У керуванні v1, пасивні зацікавлені сторони на Polkadot представляються управлінським органом, відомим як "Рада". Рада є ончейновим суб'єктом, що складається з кількох учасників, кожен з яких представляє один ончейновий рахунок. На Polkadot Рада наразі складається з членів.
Окрім контролю за державним бюджетом, Рада також головним чином відповідає за три управлінські завдання:
Розумне голосування за пропозицію
Скасування небезпечних або шкідливих референдумів
Виборча технічна комісія
У керуванні v2 потрібна заміна стратегії, щоб замінити обов'язки ради, які раніше виконувалися як довірений орган виборців, щоб компенсувати той факт, що багато людей обирають не брати участі в повсякденному управлінні. Gov2 базується на функції делегування голосування v1, виборці можуть вибрати передачу своїх голосів іншому виборцю в системі. Це досягається шляхом вдосконалення функції, яка називається багатократна делегація, де виборці можуть призначати різних представників для кожної категорії референдуму в системі. Таким чином, наприклад, виборець може делегувати певному суб'єкту управління якоюсь менш важливою категорією референдуму, а вибрати іншого представника для управління іншою категорією з більш значними наслідками, і все ще зберігати повні права голосу щодо будь-якої залишкової категорії.
) Скасувати референдум
У керуванні v1, якщо технічний комітет одностайно погоджується скасувати пропозицію, або якщо джерело Root ###, наприклад, sudo ###, активує цю функцію, тоді пропозицію можна скасувати. Депозит за скасовану пропозицію буде знищено.
Крім того, дві thirds голосів ради можуть скасувати референдум. Якщо пізно виявлено проблеми з пропозицією референдуму (, якщо в runtime-коді, що буде виконуватися за цією пропозицією, є помилка ), це може бути використано як останній засіб.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
19 лайків
Нагородити
19
9
Поділіться
Прокоментувати
0/400
ShamedApeSeller
· 07-04 15:22
Займатися такими справами, прикидаючись.
Переглянути оригіналвідповісти на0
LiquidationKing
· 07-04 14:13
DOT знову робить великі справи?
Переглянути оригіналвідповісти на0
LayerHopper
· 07-04 08:49
Кожного дня оновлення, що робити?
Переглянути оригіналвідповісти на0
HodlNerd
· 07-01 15:56
теорія ігор у управлінні – це круто... але ти бачив статистичний розподіл явки виборців? трохи тривожно, якщо чесно
Polkadot治理V2：Децентралізація рішень еволюційний шлях
Управління V2
Polkadot використовує складний механізм управління, який може елегантно еволюціонувати відповідно до потреб зацікавлених сторін. Його мета – забезпечити, щоб більшість прав завжди контролювала мережу.
Цей зміст може змінюватися. Протокол управління вже пройшов кілька ітерацій (v1 та v2), у майбутньому буде ще більше змін (v2.5).
Першою децентралізованою системою управління Polkadot (v1) є три основні компоненти:
Ця система на початковому етапі працювала добре, допомагаючи раціонально використовувати бюджетні кошти та своєчасно виконувати оновлення та ремонти. Але з розвитком системи потрібно постійно вдосконалювати недоліки та слідкувати за прогресом. Наприклад, у "управлінні v1" всі голоси на референдумі мають однакову вагу, і можна голосувати лише за один референдум за раз, при цьому період голосування може тривати кілька тижнів. Це призводить до того, що система схильна ретельно розглядати лише дуже незначну кількість пропозицій, а не широко розглядати кілька пропозицій. Тому з'явилася "управління v2".
"治理v2" або "Gov2" змінив спосіб щоденного прийняття рішень, зробивши голосування більш впливовим і швидким, що значно збільшило кількість колективних рішень, які може приймати система.
Після остаточної професійної перевірки коду Gov2 запуститься на Kusama. Після тестування на Kusama буде подано пропозицію щодо його розгортання на Polkadot.
Далі буде представлено основні принципи управління мережею Polkadot. Розуміння витоків управління v1 допоможе краще зрозуміти напрямок другого ітераційного процесу. Ці відмінності та розбіжності будуть підкреслені в різних підтемах.
Слід зазначити, що на даному етапі управління все ще є протоколом, що постійно розвивається. З оновленням управління v2 в мережу також розробляється план управління v2.5.
передумова
Підсумовуючи, ця мережа об'єднує кілька новаторських механізмів, включаючи функції перетворення станів без фіксованого типу, що зберігаються в ланцюзі і визначаються WebAssembly, а також кілька механізмів голосування в ланцюзі, таких як референдум з адаптивним абсолютним більшістю порогу та механізмом голосування за груповим схваленням.
Усі зміни до угоди повинні бути погоджені шляхом голосування з урахуванням прав власності.
механізм
У治理v1 активні власники токенів та рада спільно управляють рішеннями щодо оновлення мережі. Незалежно від того, чи пропозицію вносять публічні ( власники токенів ), чи рада, остаточне рішення має бути ухвалене шляхом загального голосування серед усіх власників, з урахуванням ваги за сумою застави та значенням віри.
У治理v2 є кілька змін. Новий режим управління відображає особливості децентралізації таким чином:
У Раді Gov1 виконуються ролі представника пасивних власників токенів, охоронця скарбниці та ініціатора законодавства, але зазвичай їх вважають централізованими сутностями. Для подальшої децентралізації мережі Gov2 пропонує повернути обов'язки Ради до громади.
референдум
Референдум - це простий, інклюзивний, заснований на стейкінгу механізм голосування. Кожен референдум має конкретну пропозицію, яка реалізується за допомогою виклику функцій привілеїв runtime у формі (, включаючи найпотужніший виклик set_code, який може переключити весь код runtime ).
Референдум є дискретною подією з фіксованим терміном голосування. Після закінчення терміну голосування та підрахунку голосів, у разі схвалення буде викликано відповідну функцію. Референдум завжди є бінарним; вибір може бути лише "за", "проти" або повна відмова.
У версії управління v1, референдум може бути розпочато одним із таких способів:
Усі референдуми мають відповідний період затримки виконання. Це проміжок часу між закінченням референдуму та фактичним виконанням пропозиції (, якщо вона була схвалена ).
Якщо референдум закритий і підрахунок завершено, він вважається завершеним. Якщо пропозицію затверджено, її буде заплановано для виконання. Якщо референдум чекає на результати, тобто триває голосування, він вважається незавершеним.
Якщо пропозиція подана громадськістю або радою, то існує фіксований термін виконання 28 днів. Пропозиції, подані в рамках виконання попередніх референдумів, можуть мати встановлений термін виконання за потреби. Обробка термінових пропозицій вимагає "швидкого реагування" на суттєві питання, що скорочує терміни виконання.
У Gov2 будь-хто може в будь-який час розпочати голосування та ініціювати багаторазові голосування. Gov2 запроваджує нові функції Origins( джерел) та Tracks( треків) для полегшення процесу та обробки голосувальних протоколів.
Origin може вважатися багатим дескриптором для заданого рівня привілеїв. Тепер пропоненту потрібно вибрати відповідний Origin для запиту відповідно до вимог пропозиції.
Кожен Origin асоціюється з категорією референдуму, а кожна категорія асоціюється з треком. Трек описує життєвий цикл пропозиції та є незалежним від треків інших категорій. Наявність різних незалежних треків дозволяє мережі налаштовувати динаміку референдуму відповідно до прихованих рівнів привілеїв.
Наприклад, вплив оновлення Runtime ( на екосистему при виклику set_code ) відрізняється від схвалення бюджетних чайових ( при виклику reportAwesome ), тому потрібні різні Origins, де різні ставки голосування, ставки затвердження, депозити та найменший період виконання будуть попередньо визначені в pallet.
Пропозиція референдуму
Громадське голосування
Будь-хто може запропонувати референдум, внесши мінімальну кількість токенів протягом певного періоду ( блоків ). Якщо хтось погодиться з цією пропозицією, вони можуть внести таку ж кількість токенів для вираження підтримки.
Ця операція називається "підпис". Пропозиція, що отримала найбільшу підтримку токенів, буде обрана для наступного голосування. Зверніть увагу, що це може відрізнятися від абсолютної кількості підписок; наприклад, три рахунки, які кожен закріпили по 20 DOT, "перевершать" ефективність десяти рахунків, які кожен закріпили по 1 DOT.
Як тільки пропозиція буде подана (, розпочнеться голосування ), пов'язані токени будуть звільнені.
Управління v1 може мати до 100 громадських пропозицій у черзі пропозицій.
У Gov2, коли референдум створюється, спільнота може відразу проголосувати за нього. Але цей референдум не перебуває в стані, в якому можна завершити або підрахувати голоси, затвердити та врешті-решт виконати. Натомість, референдум повинен відповідати певним критеріям, щоб перейти в стан "вирішення (Deciding)". Перед входженням у цей стан він залишається в стані невизначеності.
Стандарти для переходу в стан Decided такі:
Громадське голосування (v1)
Рада одноголосно проголосувала - коли всі члени ради погоджуються з пропозицією, її можна винести на голосування. Це голосування призведе до негативного відхилення голосування (, тобто чим менше голосів за, тим менше потрібно для прийняття - див. адаптивні групові упередження ).
Більшість ради проголосувала - коли лише проста більшість членів ради погоджується, можна також голосувати за референдум, але це буде система більшості, де переможе сторона, яка отримає 51% голосів (.
В будь-який момент може бути тільки один дійсний референдум, якщо тільки немає ще одного термінового референдуму.
Графік голосування
У Governance v1, якщо в одному з черг є принаймні одна пропозиція, нове голосування відбуватиметься кожні 28 днів. Пропозиції, затверджені радою, мають свою чергу, а пропозиції, подані громадськістю, також мають свою чергу. Голосування буде чергуватися між пропозиціями, що займають перші місця в обох чергах.
Найбільш пріоритетна пропозиція визначається кількістю стейків, які пов'язані з нею. Якщо поточна черга намагається створити референдум без пропозицій ) черга пуста (, і в іншій черзі є пропозиції в черзі, то найпершою пропозицією з іншої черги буде проведено референдум.
Не можна голосувати за декілька референдумів одночасно, за винятком термінових референдумів. Термінові референдуми, які відбуваються одночасно з звичайними референдумами ), що проводяться публічно або за пропозицією ради (, є єдиною ситуацією, коли можна голосувати за декілька референдумів одночасно.
Коли пропозиція буде схвалена, управління v2 матиме однаковий 28-денний період кваліфікації. Якщо на завершення цього етапу пропозиція все ще не буде схвалена, вона буде автоматично відхилена.
Голосування на референдумі ) управління v2(
У Governance v2, якщо пропозиція відповідає вимогам щодо рівня схвалення і підтримки, ця пропозиція буде затверджена, тобто було видалено адаптивну систему групових упереджень.
Ставка схвалення ) визначається як вага голосів за схвалення ( після коректування переконаності ) у загальному вазі голосів (, що включає частки схвалення та відхилення ).
Підтримка ( Support ) є загальною кількістю голосів, затверджених ( ігноруючи корекції переконання ) в порівнянні з загальною кількістю голосів, які можуть бути здійснені в системі.
Це повинно бути виконано в найкоротший термін підтвердження. Різні траєкторії мають різні терміни підтвердження та вимоги до схвалення та підтримки. Тепер можна налаштувати через необхідну кількість підтримки та загальне схвалення. Для пропозицій, що використовують джерела з нижчими привілеями, зниження необхідного відсотка голосування до більш реалістичної цифри є більш доцільним у порівнянні з пропозиціями, що використовують категорії з вищими привілеями (, такими як Root). Пропозиції, які мають велике політичне значення, можуть раніше вимагати вищого схвалення, щоб уникнути суперечок.
У Gov2, пропозиції, які не були схвалені протягом 28 днів, вважаються автоматично відхиленими, і Decision Deposit буде повернуто. Якщо пропозиція зможе залишитися затвердженою до закінчення періоду підтвердження, вона вважається схваленою і планується виконати її з джерела пропозиції після періоду розробки. Період розробки визначається під час голосування всього населення, але також підлягає мінімуму, заснованому на треках. Потужніші треки будуть примушувати до довшого періоду виконання, щоб забезпечити мережу достатнім часом для підготовки до будь-яких змін, які пропозиція може принести.
Добровільне блокування
Polkadot використовує концепцію "добровільного блокування", що дозволяє власникам токенів збільшувати свої голосувальні права шляхом заявлення про готовність заблокувати токени на певний термін. Таким чином, кількість голосів для кожного власника токенів буде обчислюватися за наступною формулою:
Кількість голосів = токен * множник переконання
Кількість термінів блокування подвоюється, множник переконання збільшить множник голосування на одиницю.
Кількість термінів блокування Множник голосування 0 1 1 2 2 3 4 4 8 5 16 6 32 6
Максимальна кількість налаштувань "подвоєння" терміна блокування встановлена на 6(, отже, всього 32 терміни блокування ), один термін блокування дорівнює 28 дням. Дозволено лише подвоєння, наприклад, ви не можете заблокувати 24 періоди і збільшити вашу переконаність на 5.5.
після блокування токена ви все ще можете використовувати його для голосування та стейкінгу; вам заборонено лише переводити ці токени на інший рахунок.
Голосування завжди "обчислюється" в один і той же час, тобто по закінченні періоду голосування. Це не підлягає впливу терміну блокування токенів.
Адаптивні групові упередження
Адаптивне групове відхилення використовувалося в Governance v2 довше і було замінене системою Approval/Support.
( Рада
У керуванні v1, пасивні зацікавлені сторони на Polkadot представляються управлінським органом, відомим як "Рада". Рада є ончейновим суб'єктом, що складається з кількох учасників, кожен з яких представляє один ончейновий рахунок. На Polkadot Рада наразі складається з членів.
Окрім контролю за державним бюджетом, Рада також головним чином відповідає за три управлінські завдання:
У керуванні v2 потрібна заміна стратегії, щоб замінити обов'язки ради, які раніше виконувалися як довірений орган виборців, щоб компенсувати той факт, що багато людей обирають не брати участі в повсякденному управлінні. Gov2 базується на функції делегування голосування v1, виборці можуть вибрати передачу своїх голосів іншому виборцю в системі. Це досягається шляхом вдосконалення функції, яка називається багатократна делегація, де виборці можуть призначати різних представників для кожної категорії референдуму в системі. Таким чином, наприклад, виборець може делегувати певному суб'єкту управління якоюсь менш важливою категорією референдуму, а вибрати іншого представника для управління іншою категорією з більш значними наслідками, і все ще зберігати повні права голосу щодо будь-якої залишкової категорії.
) Скасувати референдум
У керуванні v1, якщо технічний комітет одностайно погоджується скасувати пропозицію, або якщо джерело Root ###, наприклад, sudo ###, активує цю функцію, тоді пропозицію можна скасувати. Депозит за скасовану пропозицію буде знищено.
Крім того, дві thirds голосів ради можуть скасувати референдум. Якщо пізно виявлено проблеми з пропозицією референдуму (, якщо в runtime-коді, що буде виконуватися за цією пропозицією, є помилка ), це може бути використано як останній засіб.
якщо скасовані суперечки достатньо великі, щоб