Полка використовує витончену механіку управління, яка дозволяє їй постійно еволюціонувати відповідно до потреб зацікавлених сторін. Її мета - забезпечити контроль над мережею більшості прав.
Цей зміст може змінюватися. Угода про управління пройшла кілька ітерацій (v1 та v2), в майбутньому буде ще більше змін (v2.5).
Першою децентралізованою системою управління Polkadot (v1) є три основні компоненти:
Технічний комітет: керування графіком оновлень
Рада: виконавчий "уряд", обраний шляхом виборів, відповідальний за управління параметрами, управління та витратними пропозиціями
Референдум: загальна система голосування, що надає більший вплив довготривалим зацікавленим сторонам
Система спочатку працювала добре в перші кілька років, але з часом вона повинна постійно еволюціонувати, щоб покращити недоліки та встигати за прогресом. Наприклад, у "управлінні v1" всі голоси мали однакову вагу, можна було голосувати лише за один референдум за раз, а термін голосування міг тривати кілька тижнів. Це призвело до того, що система схилялася до ретельного розгляду дуже небагатьох пропозицій, а не до широкого розгляду кількох пропозицій. Тому з'явилося "управління v2".
"治理v2" або "Gov2" змінив методи прийняття рішень у повсякденному житті, зробивши вплив референдумів ширшим і більш гнучким, що в свою чергу значно збільшило кількість колективних рішень, які система може приймати.
Gov2 буде запущено та протестовано на Kusama, після чого буде запропоновано розгорнути його на Polkadot. Наразі Gov2 вже запущено в мережі Kusama.
Наступний зміст представить основні принципи управління мережею Polkadot. Розуміння коренів управління v1 допоможе краще зрозуміти напрямок другого ітераційного етапу. Ці відмінності будуть підкреслені в різних підтемах.
Слід зазначити, що на даному етапі управління все ще є протоколом, що постійно розвивається. З оновленням управління v2 також розробляється план управління v2.5.
передумова
Підсумовуючи, ця мережа об'єднує різноманітні новаторські механізми, включаючи функцію безформних станів, що зберігається в ланцюгу (, визначену за допомогою WebAssembly ), а також різні механізми голосування в ланцюзі, такі як референдум з адаптивним абсолютним більшістю порогом і голосування з масовим схваленням.
Усі зміни до угоди повинні бути узгоджені через голосування з урахуванням прав.
механізм
У керуванні v1 активні тримачі токенів та рада спільно управляють рішеннями щодо оновлення мережі. Незалежно від того, чи пропозицію висунула публіка, чи рада, остаточне рішення має бути ухвалено шляхом загального голосування з урахуванням суми застави та значення віри.
У治理v2 є кілька змін. Новий режим управління відображає ознаки децентралізації таким чином:
Передача відповідальності ради акціонерам через демократичне голосування
Розпустити чинну раду директорів
Дозволити користувачам делегувати свої голоси членам спільноти різними способами
референдум
Голосування є простим, інклюзивним, заснованим на стейкінгу варіантом голосування. Кожне голосування має відповідну пропозицію, що використовує виклики функцій привілеїв runtime у формі (, включаючи найпотужніший виклик set_code, який може переключати весь код runtime ).
Референдум є дискретною подією з фіксованим терміном голосування. Після закінчення терміну голосування та підрахунку голосів, якщо отримано схвалення, буде викликано відповідну функцію. Референдум завжди є бінарним; варіанти голосування можуть бути "за", "проти" або повністю утриматися.
У治理v1, громадське голосування можна ініціювати кількома способами:
Публічно подані пропозиції
Пропозиції, ухвалені більшістю голосів або одностайно на раді
Подані пропозиції в рамках попереднього референдуму
Термінова пропозиція, подана технічним комітетом та затверджена правлінням.
Усі референдуми мають відповідний період затримки виконання. Це проміжок часу між закінченням референдуму та фактичним виконанням пропозиції.
У Gov2 будь-хто може в будь-який час ініціювати референдум без обмеження кількості. Gov2 вводить концепції Origins( джерела) та Tracks( траси), щоб полегшити процеси та обробку референдумів.
Origin можна вважати дескриптором, що відповідає заданому рівню привілеїв. Пропоненту необхідно обрати відповідний Origin для запиту відповідно до вимог пропозиції.
Кожен Origin пов'язаний з категорією референдуму, кожна категорія має Track. Track описує життєвий цикл пропозиції і є незалежним від інших категорій. Різні незалежні треки дозволяють мережі коригувати динаміку референдуму відповідно до прихованого рівня привілеїв.
Наприклад, вплив оновлення Runtime на екосистему відрізняється від схвалення казначейських чайових, тому потребуються різні Origins, де різні рівні голосування, схвалення, депозит та найменший період виконання будуть попередньо визначені.
Пропозиція референдуму
Громадське голосування
Будь-хто може запропонувати референдум, внесши мінімальну кількість токенів протягом визначеного періоду. Якщо хтось погоджується, вони можуть внести таку ж кількість токенів як підтримку.
Це називається "підтримка". Пропозиція, яка отримає найвищу підтримку токенів, буде обрана для наступного голосування. Зверніть увагу, що це може відрізнятися від абсолютної кількості підтримки; наприклад, три облікові записи, кожен з яких має 20 DOT, "перевищать" десять облікових записів, кожен з яких має 1 DOT.
Як тільки пропозиція буде подана ( для голосування ), прив'язані токени будуть випущені.
У системі управління v1 у черзі пропозицій може бути не більше 100 загальних пропозицій.
У Gov2, після створення референдуму, спільнота може негайно голосувати. Але цей референдум не знаходиться в стані, в якому його можна завершити, підрахувати голоси, отримати затвердження та остаточно виконати. Натомість, референдум повинен відповідати певним критеріям, щоб перейти в стан "вирішення (Deciding)". До цього часу він залишається в підвішеному стані.
Стандарти для переходу в стан Decided такі:
Період імплементації пройдено, це час, який потрібно пройти перед початком прийняття рішення. Це допомагає зменшити ймовірність "рішення-удару", коли атакуючий, який контролює велику частину голосів, може відразу ж схвалити пропозицію після її внесення, не давши всім виборцям достатньо часу для роздумів і участі.
Має бути ще простір для прийняття рішень. Всі треки мають обмеження на кількість голосувань, які можуть бути проведені одночасно. Потужніші треки мають нижчі обмеження. Наприклад, обмеження для Origin рівня Root становить 1, що означає, що можна приймати рішення лише про 1 надзвичайно небезпечну пропозицію одночасно.
Необхідно сплатити депозит для ухвалення рішення. Створення референдуму коштує дуже мало, оскільки депозит лише включає вартість, необхідну для зберігання даних у ланцюзі. Але перевірка та ухвалення рішення щодо референдуму несе ризик вичерпання обмеженого місця в черзі референдумів. Вимога надання більшого, але повертаємого депозиту допомагає зменшити спам.
Голосування ради (v1)
Рада одноголосно ухвалила - коли всі члени ради погоджуються з пропозицією, її можна винести на референдум. Цей референдум призведе до негативного відхилення голосування (, тобто чим менше голосів за права, тим менше голосів потрібно для ухвалення ).
Більшість ради схвалила - коли лише проста більшість членів ради погоджується, також може бути проведено голосування на референдумі, але це буде система більшості голосів, де сторона, що отримала 51% голосів, виграє (.
В будь-який час може бути лише один дійсний референдум, якщо тільки немає термінового референдуму.
Графік голосування
У версії управління v1, якщо у черзі є принаймні одна пропозиція, кожні 28 днів буде проводитися нове голосування. Пропозиції, затверджені ради, мають свою чергу, а пропозиції, подані громадськістю, також мають свою чергу. Голосування буде чергуватися між пропозиціями, що займають перші місця в двох чергах.
Рейтинг найкращих пропозицій визначається кількістю закладених коштів, які стоять за ними. Якщо поточний черговий вибір намагається створити голосування без пропозицій ) черга пуста (, а в іншій черзі є пропозиції в черзі, то найкраща пропозиція з іншої черги увійде до голосування.
Не можна голосувати за кілька референдумів одночасно, за винятком термінових референдумів. Терміновий референдум, що відбувається одночасно з регулярними референдумами, є єдиним випадком, коли можна голосувати за кілька референдумів.
Коли пропозиція буде затверджена, управління v2 поділиться тим самим 28-денним періодом кваліфікації. Якщо на момент закінчення цього етапу вона все ще не буде затверджена, ця пропозиція автоматично буде відхилена.
Громадське голосування ) управління v2(
У керуванні v2, якщо пропозиція відповідає вимогам щодо рівня схвалення та підтримки, ця пропозиція буде схвалена, тобто буде видалена адаптивна система упередження групи.
Коефіцієнт схвалення ) визначається як вага голосування за схвалення ( після корекції переконання ) у загальній вазі голосування (, що включає частки схвалення та відмови ).
Підтримка (Support) є загальною кількістю голосів, затверджених ( ігноруючи коригування переконань ) для порівняння з загальною кількістю голосів, які можуть бути здійснені в системі.
Він повинен відповідати цим стандартам у найкоротші терміни підтвердження. Різні траєкторії мають різні терміни підтвердження та вимоги до затвердження і підтримки. Тепер можна налаштувати через необхідну кількість підтримки та загальне затвердження. Для пропозицій, що використовують джерела з нижчими привілеями, більш доцільно знизити необхідний відсоток голосування до більш реалістичної кількості раніше, ніж для пропозицій, що використовують категорії з високими привілеями (, такі як Root). Курс з великою політичною значущістю може заздалегідь вимагати більшого затвердження, щоб уникнути суперечок.
У Gov2, через 28 днів невApproved пропозиції вважатимуться автоматично відхиленими, і Decision Deposit буде повернуто. Якщо пропозиція залишається схваленою до закінчення періоду підтвердження, вона вважається затвердженою та планується до виконання з джерела пропозиції після періоду розробки. Період розробки визначається під час пропозиції загального голосування, але також підлягає мінімуму, заснованому на треках. Більш потужні треки забезпечать триваліший період виконання, щоб гарантовано дати мережі достатньо часу для підготовки до змін, які можуть викликати пропозиції.
Добровільне блокування
Polkadot використовує концепцію "добровільної блокування", що дозволяє тримачам токенів збільшити свою виборчу вагу, заявивши, на який час вони готові заблокувати токени. Таким чином, кількість голосів кожного тримача токенів буде розраховуватися за наступною формулою:
Кількість голосів = токен * множник переконання
Кількість періодів блокування подвоюється, множник переконання буде збільшувати множник голосування на одиницю.
Множник голосування за термін блокування 00.111224384165326
Максимальна кількість налаштувань "подвоєння" терміну блокування встановлена на 6(, всього 32 терміни блокування ), один термін блокування дорівнює 28 дням. Дозволяється тільки подвоєння, наприклад, не можна заблокувати 24 цикли і збільшити переконання на 5.5.
Токени, які були заблоковані, все ще можна використовувати для голосування та стейкінгу; лише заборонено переносити ці токени на інший рахунок.
Голосування завжди "рахується" в один і той же час, тобто після закінчення терміну голосування. Це не підлягає впливу терміна блокування токенів.
Адаптивні групові упередження
Адаптивні групові відхилення використовувалися в управлінні v2 довше і були замінені системою Approval/Support.
( Рада
В управлінні v1, пасивні учасники на Polkadot представлені керівним органом, званим "Радою". Рада є ончейн-структурою, що складається з кількох учасників, кожен з яких представляє один ончейн-рахунок. На Polkadot рада наразі складається з членів.
Окрім контролю за державним бюджетом, Рада також відповідає за три основні завдання управління:
Розумне голосування за пропозиції
Скасування небезпечних або шкідливих референдумів
Технічний комітет виборів
У управлінні v2 необхідні альтернативні стратегії для заміни обов'язків ради, які раніше виконувала як агентство делегатів виборців, щоб компенсувати той факт, що багато людей вибирають не брати участь у повсякденному управлінні. Gov2 базується на функції делегування голосування v1, де виборці можуть вибрати, щоб делегувати свої голоси іншому виборцю в системі. Це реалізується шляхом вдосконалення функції, що називається багатостороннім делегуванням, де виборці можуть призначати різних представників для кожної категорії референдумів у системі. Таким чином, виборці можуть делегувати певній сутності управління певною категорією референдумів, яка має незначний вплив, і вибрати іншого різного представника для управління іншим, що має більш серйозні наслідки, і все ще зберігати повні права голосу для будь-яких залишкових категорій.
) Скасувати референдум
У рамках керування v1, якщо технічний комітет одностайно погоджується скасувати пропозицію, або якщо джерело Root ###, як sudo ###, викликає цю функцію, пропозицію можна скасувати. Депозит скасованих пропозицій буде знищено.
Крім того, дві третини голосів ради можуть скасувати референдум. Якщо проблеми з пропозицією референдуму виявляються пізно (, наприклад, якщо в коді runtime, що підлягає виконанню за цією пропозицією, є помилка ), це може бути використано як останній засіб.
Якщо спір, що скасування, є настільки великим, що рада не може досягти двох третіх більшості, тоді долю пропозиції буде вирішуватися спільно зацікавленими сторонами.
У управлінні v2 є спеціальна операція під назвою Cancelation(, яка використовується для втручання в уже проголосовану пропозицію. Ця операція негайно відхиляє поточне голосування, незалежно від його статусу. Існує також положення, що якщо пропозиція є злочинною або спамом, забезпечується конфіскація застави пропонента.
Скасування саме по собі є управлінською операцією, яка повинна бути виконана шляхом голосування в мережі. Скасування супроводжується своїм власним Origin і Track, має дуже короткий період імпорту та криву схвалення/підтримки, яка трохи швидше знижується через поріг, оскільки вона викликається лише в термінових ситуаціях.
) Технічний комітет
У управлінні v1, Технічний комітет (TC) є одним із трьох院 управління Kusama ###, інші два院 - це Рада та Голосування (. TC складається з команд, які успішно реалізували або визначили Polkadot runtime або Polkadot Host. Через просту більшість голосів Ради можна додавати чи видаляти команди в TC.
Мета TC полягає в запобіганні зловмисним голосуванням, реалізації виправлень помилок, скасуванні помилкових оновлень runtime або додаванні нових, але перевірених на практиці функцій. TC має право використовувати палету Democracy для прискорення пропозицій і є єдиним, хто може
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
15 лайків
Нагородити
15
8
Поділіться
Прокоментувати
0/400
MetaMuskRat
· 07-30 04:17
А v2 також не має якихось великих змін.
Переглянути оригіналвідповісти на0
CoffeeOnChain
· 07-28 20:33
Ітерацій було стільки, як справи?
Переглянути оригіналвідповісти на0
ApyWhisperer
· 07-28 18:01
Управління справді ароматне, коли піднімемося до v3.
Покерне управління V2: нова глава децентралізованого прийняття рішень
Управління V2
Полка використовує витончену механіку управління, яка дозволяє їй постійно еволюціонувати відповідно до потреб зацікавлених сторін. Її мета - забезпечити контроль над мережею більшості прав.
Цей зміст може змінюватися. Угода про управління пройшла кілька ітерацій (v1 та v2), в майбутньому буде ще більше змін (v2.5).
Першою децентралізованою системою управління Polkadot (v1) є три основні компоненти:
Система спочатку працювала добре в перші кілька років, але з часом вона повинна постійно еволюціонувати, щоб покращити недоліки та встигати за прогресом. Наприклад, у "управлінні v1" всі голоси мали однакову вагу, можна було голосувати лише за один референдум за раз, а термін голосування міг тривати кілька тижнів. Це призвело до того, що система схилялася до ретельного розгляду дуже небагатьох пропозицій, а не до широкого розгляду кількох пропозицій. Тому з'явилося "управління v2".
"治理v2" або "Gov2" змінив методи прийняття рішень у повсякденному житті, зробивши вплив референдумів ширшим і більш гнучким, що в свою чергу значно збільшило кількість колективних рішень, які система може приймати.
Gov2 буде запущено та протестовано на Kusama, після чого буде запропоновано розгорнути його на Polkadot. Наразі Gov2 вже запущено в мережі Kusama.
Наступний зміст представить основні принципи управління мережею Polkadot. Розуміння коренів управління v1 допоможе краще зрозуміти напрямок другого ітераційного етапу. Ці відмінності будуть підкреслені в різних підтемах.
Слід зазначити, що на даному етапі управління все ще є протоколом, що постійно розвивається. З оновленням управління v2 також розробляється план управління v2.5.
передумова
Підсумовуючи, ця мережа об'єднує різноманітні новаторські механізми, включаючи функцію безформних станів, що зберігається в ланцюгу (, визначену за допомогою WebAssembly ), а також різні механізми голосування в ланцюзі, такі як референдум з адаптивним абсолютним більшістю порогом і голосування з масовим схваленням.
Усі зміни до угоди повинні бути узгоджені через голосування з урахуванням прав.
механізм
У керуванні v1 активні тримачі токенів та рада спільно управляють рішеннями щодо оновлення мережі. Незалежно від того, чи пропозицію висунула публіка, чи рада, остаточне рішення має бути ухвалено шляхом загального голосування з урахуванням суми застави та значення віри.
У治理v2 є кілька змін. Новий режим управління відображає ознаки децентралізації таким чином:
референдум
Голосування є простим, інклюзивним, заснованим на стейкінгу варіантом голосування. Кожне голосування має відповідну пропозицію, що використовує виклики функцій привілеїв runtime у формі (, включаючи найпотужніший виклик set_code, який може переключати весь код runtime ).
Референдум є дискретною подією з фіксованим терміном голосування. Після закінчення терміну голосування та підрахунку голосів, якщо отримано схвалення, буде викликано відповідну функцію. Референдум завжди є бінарним; варіанти голосування можуть бути "за", "проти" або повністю утриматися.
У治理v1, громадське голосування можна ініціювати кількома способами:
Усі референдуми мають відповідний період затримки виконання. Це проміжок часу між закінченням референдуму та фактичним виконанням пропозиції.
У Gov2 будь-хто може в будь-який час ініціювати референдум без обмеження кількості. Gov2 вводить концепції Origins( джерела) та Tracks( траси), щоб полегшити процеси та обробку референдумів.
Origin можна вважати дескриптором, що відповідає заданому рівню привілеїв. Пропоненту необхідно обрати відповідний Origin для запиту відповідно до вимог пропозиції.
Кожен Origin пов'язаний з категорією референдуму, кожна категорія має Track. Track описує життєвий цикл пропозиції і є незалежним від інших категорій. Різні незалежні треки дозволяють мережі коригувати динаміку референдуму відповідно до прихованого рівня привілеїв.
Наприклад, вплив оновлення Runtime на екосистему відрізняється від схвалення казначейських чайових, тому потребуються різні Origins, де різні рівні голосування, схвалення, депозит та найменший період виконання будуть попередньо визначені.
Пропозиція референдуму
Громадське голосування
Будь-хто може запропонувати референдум, внесши мінімальну кількість токенів протягом визначеного періоду. Якщо хтось погоджується, вони можуть внести таку ж кількість токенів як підтримку.
Це називається "підтримка". Пропозиція, яка отримає найвищу підтримку токенів, буде обрана для наступного голосування. Зверніть увагу, що це може відрізнятися від абсолютної кількості підтримки; наприклад, три облікові записи, кожен з яких має 20 DOT, "перевищать" десять облікових записів, кожен з яких має 1 DOT.
Як тільки пропозиція буде подана ( для голосування ), прив'язані токени будуть випущені.
У системі управління v1 у черзі пропозицій може бути не більше 100 загальних пропозицій.
У Gov2, після створення референдуму, спільнота може негайно голосувати. Але цей референдум не знаходиться в стані, в якому його можна завершити, підрахувати голоси, отримати затвердження та остаточно виконати. Натомість, референдум повинен відповідати певним критеріям, щоб перейти в стан "вирішення (Deciding)". До цього часу він залишається в підвішеному стані.
Стандарти для переходу в стан Decided такі:
Період імплементації пройдено, це час, який потрібно пройти перед початком прийняття рішення. Це допомагає зменшити ймовірність "рішення-удару", коли атакуючий, який контролює велику частину голосів, може відразу ж схвалити пропозицію після її внесення, не давши всім виборцям достатньо часу для роздумів і участі.
Має бути ще простір для прийняття рішень. Всі треки мають обмеження на кількість голосувань, які можуть бути проведені одночасно. Потужніші треки мають нижчі обмеження. Наприклад, обмеження для Origin рівня Root становить 1, що означає, що можна приймати рішення лише про 1 надзвичайно небезпечну пропозицію одночасно.
Необхідно сплатити депозит для ухвалення рішення. Створення референдуму коштує дуже мало, оскільки депозит лише включає вартість, необхідну для зберігання даних у ланцюзі. Але перевірка та ухвалення рішення щодо референдуму несе ризик вичерпання обмеженого місця в черзі референдумів. Вимога надання більшого, але повертаємого депозиту допомагає зменшити спам.
Голосування ради (v1)
Рада одноголосно ухвалила - коли всі члени ради погоджуються з пропозицією, її можна винести на референдум. Цей референдум призведе до негативного відхилення голосування (, тобто чим менше голосів за права, тим менше голосів потрібно для ухвалення ).
Більшість ради схвалила - коли лише проста більшість членів ради погоджується, також може бути проведено голосування на референдумі, але це буде система більшості голосів, де сторона, що отримала 51% голосів, виграє (.
В будь-який час може бути лише один дійсний референдум, якщо тільки немає термінового референдуму.
Графік голосування
У версії управління v1, якщо у черзі є принаймні одна пропозиція, кожні 28 днів буде проводитися нове голосування. Пропозиції, затверджені ради, мають свою чергу, а пропозиції, подані громадськістю, також мають свою чергу. Голосування буде чергуватися між пропозиціями, що займають перші місця в двох чергах.
Рейтинг найкращих пропозицій визначається кількістю закладених коштів, які стоять за ними. Якщо поточний черговий вибір намагається створити голосування без пропозицій ) черга пуста (, а в іншій черзі є пропозиції в черзі, то найкраща пропозиція з іншої черги увійде до голосування.
Не можна голосувати за кілька референдумів одночасно, за винятком термінових референдумів. Терміновий референдум, що відбувається одночасно з регулярними референдумами, є єдиним випадком, коли можна голосувати за кілька референдумів.
Коли пропозиція буде затверджена, управління v2 поділиться тим самим 28-денним періодом кваліфікації. Якщо на момент закінчення цього етапу вона все ще не буде затверджена, ця пропозиція автоматично буде відхилена.
Громадське голосування ) управління v2(
У керуванні v2, якщо пропозиція відповідає вимогам щодо рівня схвалення та підтримки, ця пропозиція буде схвалена, тобто буде видалена адаптивна система упередження групи.
Коефіцієнт схвалення ) визначається як вага голосування за схвалення ( після корекції переконання ) у загальній вазі голосування (, що включає частки схвалення та відмови ).
Підтримка (Support) є загальною кількістю голосів, затверджених ( ігноруючи коригування переконань ) для порівняння з загальною кількістю голосів, які можуть бути здійснені в системі.
Він повинен відповідати цим стандартам у найкоротші терміни підтвердження. Різні траєкторії мають різні терміни підтвердження та вимоги до затвердження і підтримки. Тепер можна налаштувати через необхідну кількість підтримки та загальне затвердження. Для пропозицій, що використовують джерела з нижчими привілеями, більш доцільно знизити необхідний відсоток голосування до більш реалістичної кількості раніше, ніж для пропозицій, що використовують категорії з високими привілеями (, такі як Root). Курс з великою політичною значущістю може заздалегідь вимагати більшого затвердження, щоб уникнути суперечок.
У Gov2, через 28 днів невApproved пропозиції вважатимуться автоматично відхиленими, і Decision Deposit буде повернуто. Якщо пропозиція залишається схваленою до закінчення періоду підтвердження, вона вважається затвердженою та планується до виконання з джерела пропозиції після періоду розробки. Період розробки визначається під час пропозиції загального голосування, але також підлягає мінімуму, заснованому на треках. Більш потужні треки забезпечать триваліший період виконання, щоб гарантовано дати мережі достатньо часу для підготовки до змін, які можуть викликати пропозиції.
Добровільне блокування
Polkadot використовує концепцію "добровільної блокування", що дозволяє тримачам токенів збільшити свою виборчу вагу, заявивши, на який час вони готові заблокувати токени. Таким чином, кількість голосів кожного тримача токенів буде розраховуватися за наступною формулою:
Кількість голосів = токен * множник переконання
Кількість періодів блокування подвоюється, множник переконання буде збільшувати множник голосування на одиницю.
Множник голосування за термін блокування 00.111224384165326
Максимальна кількість налаштувань "подвоєння" терміну блокування встановлена на 6(, всього 32 терміни блокування ), один термін блокування дорівнює 28 дням. Дозволяється тільки подвоєння, наприклад, не можна заблокувати 24 цикли і збільшити переконання на 5.5.
Токени, які були заблоковані, все ще можна використовувати для голосування та стейкінгу; лише заборонено переносити ці токени на інший рахунок.
Голосування завжди "рахується" в один і той же час, тобто після закінчення терміну голосування. Це не підлягає впливу терміна блокування токенів.
Адаптивні групові упередження
Адаптивні групові відхилення використовувалися в управлінні v2 довше і були замінені системою Approval/Support.
( Рада
В управлінні v1, пасивні учасники на Polkadot представлені керівним органом, званим "Радою". Рада є ончейн-структурою, що складається з кількох учасників, кожен з яких представляє один ончейн-рахунок. На Polkadot рада наразі складається з членів.
Окрім контролю за державним бюджетом, Рада також відповідає за три основні завдання управління:
У управлінні v2 необхідні альтернативні стратегії для заміни обов'язків ради, які раніше виконувала як агентство делегатів виборців, щоб компенсувати той факт, що багато людей вибирають не брати участь у повсякденному управлінні. Gov2 базується на функції делегування голосування v1, де виборці можуть вибрати, щоб делегувати свої голоси іншому виборцю в системі. Це реалізується шляхом вдосконалення функції, що називається багатостороннім делегуванням, де виборці можуть призначати різних представників для кожної категорії референдумів у системі. Таким чином, виборці можуть делегувати певній сутності управління певною категорією референдумів, яка має незначний вплив, і вибрати іншого різного представника для управління іншим, що має більш серйозні наслідки, і все ще зберігати повні права голосу для будь-яких залишкових категорій.
) Скасувати референдум
У рамках керування v1, якщо технічний комітет одностайно погоджується скасувати пропозицію, або якщо джерело Root ###, як sudo ###, викликає цю функцію, пропозицію можна скасувати. Депозит скасованих пропозицій буде знищено.
Крім того, дві третини голосів ради можуть скасувати референдум. Якщо проблеми з пропозицією референдуму виявляються пізно (, наприклад, якщо в коді runtime, що підлягає виконанню за цією пропозицією, є помилка ), це може бути використано як останній засіб.
Якщо спір, що скасування, є настільки великим, що рада не може досягти двох третіх більшості, тоді долю пропозиції буде вирішуватися спільно зацікавленими сторонами.
У управлінні v2 є спеціальна операція під назвою Cancelation(, яка використовується для втручання в уже проголосовану пропозицію. Ця операція негайно відхиляє поточне голосування, незалежно від його статусу. Існує також положення, що якщо пропозиція є злочинною або спамом, забезпечується конфіскація застави пропонента.
Скасування саме по собі є управлінською операцією, яка повинна бути виконана шляхом голосування в мережі. Скасування супроводжується своїм власним Origin і Track, має дуже короткий період імпорту та криву схвалення/підтримки, яка трохи швидше знижується через поріг, оскільки вона викликається лише в термінових ситуаціях.
) Технічний комітет
У управлінні v1, Технічний комітет (TC) є одним із трьох院 управління Kusama ###, інші два院 - це Рада та Голосування (. TC складається з команд, які успішно реалізували або визначили Polkadot runtime або Polkadot Host. Через просту більшість голосів Ради можна додавати чи видаляти команди в TC.
Мета TC полягає в запобіганні зловмисним голосуванням, реалізації виправлень помилок, скасуванні помилкових оновлень runtime або додаванні нових, але перевірених на практиці функцій. TC має право використовувати палету Democracy для прискорення пропозицій і є єдиним, хто може