Зміст

Відмова від відповідальності: робота ще триває. Механізми піддаються змінам.

Процес управління поділяється на кілька кроків, які описано нижче:

• Подання пропозиції: Пропозиція подається в блокчейн із депозитом.

• Голосування: коли депозит досягне певної величини (MinDeposit), пропозиція підтверджується та починається голосування. Власники зв’язаних NOM можуть потім надсилати транзакції TxGovVote для голосування за пропозицію.

• Якщо пропозиція передбачає оновлення програмного забезпечення:

  • Сигнал: валідатори починають сигналізувати, що вони готові перейти на нову версію.

  • Перемикання: коли понад 75% валідаторів сигналізують про готовність до переходу, їх програмне забезпечення автоматично перемикається на нову версію.

#Подання позиції

#Право подати пропозицію

Будь-який власник NOM, зв’язаний чи не зв’язаний, може подати пропозиції, надіславши транзакцію TxGovProposal. Після подання пропозиції вона ідентифікується за унікальним ідентифікатором пропозиції.

#Типи пропозицій

У початковій версії модуля управління є п’ять типів пропозицій:

• TextProposal До цього типу відносяться всі пропозиції, які не передбачають модифікації вихідного коду. Наприклад, опитування громадської думки використовуватиме пропозицію типу TextProposal.

• SoftwareUpgradeProposal. У разі прийняття валідатори мають оновити своє програмне забезпечення відповідно до пропозиції. Вони повинні зробити це, виконавши 2-етапний процес, описаний у розділі Оновлення програмного забезпечення нижче. Дорожню карту оновлення програмного забезпечення можна обговорити та погодити через TextProposals, але фактичне оновлення програмного забезпечення має здійснюватися через SoftwareUpgradeProposals.

• CommunityPoolSpendProposal деталізує пропозицію щодо використання коштів спільноти, а також кількість монет, які пропонується витратити, і на який рахунок одержувача.

• ParameterChangeProposal визначає пропозицію змінити один або більше параметрів. Якщо прийнято, запрошена зміна параметра автоматично оновлюється обробником пропозиції після завершення періоду голосування.

• CancelSoftwareUpgradeProposal — це тип вмісту gov для скасування оновлення програмного забезпечення.

Інші модулі можуть розширювати модуль управління шляхом реалізації власних типів пропозицій і обробників. Ці типи реєструються та обробляються через модуль управління (наприклад, ParamChangeProposal), який потім виконує обробник пропозицій відповідного модуля, коли пропозиція проходить. Цей спеціальний обробник може виконувати довільні зміни стану.

#Депозит

Щоб запобігти спаму, пропозиції потрібно надсилати з депозитом у монетах, визначених у параметрі MinDeposit. Період голосування не розпочнеться, доки депозит пропозиції не дорівнюватиме MinDeposit.

Коли пропозиція подається, вона має супроводжуватися депозитом, який має бути суто позитивним, але може бути нижчим за MinDeposit. Заявнику не потрібно оплачувати весь депозит самостійно. Якщо депозит пропозиції нижчий від MinDeposit, інші власники токенів можуть збільшити депозит пропозиції, надіславши транзакцію Deposit. Депозит зберігається на умовному депонуванні в управлінському ModuleAccount, доки пропозиція не буде завершена (прийнято чи відхилено).

Коли депозит пропозиції досягне MinDeposit, він переходить у період голосування. Якщо депозит пропозиції не досягне MinDeposit до MaxDepositPeriod, пропозиція закривається, і ніхто більше не зможе внести на нього депозит.

#Повернення депозиту та спалювання

Коли пропозиція завершена, монети з депозиту або повертаються, або спалюються, відповідно до остаточного підрахунку пропозиції:

• Якщо пропозицію схвалено або якщо на неї відхилено, але не накладено вето, депозити будуть автоматично повернені відповідному вкладнику (передано з керуючого ModuleAccount).

• Якщо на пропозицію буде накладено вето супербільшістю, депозити будуть спалені з ModuleAccount управління.

#Голосуйте

#Учасники

Учасники - це користувачі, які мають право голосу за пропозиції. У Onomy Hub учасники є пов’язаними власниками NOM. Непідключені власники NOM та інші користувачі не отримують права брати участь в управлінні. Однак вони можуть подавати та депонувати пропозиції.

Зверніть увагу, що деяким учасникам може бути заборонено голосувати за пропозицію під певним валідатором, якщо:

• учасник прив’язав або не прив’язав NOM до зазначеного валідатора після того, як пропозиція ввійшла в період голосування.

• учасник став валідатором після того, як пропозиція вступила в період голосування.

Це не заважає учаснику голосувати за допомогою NOM, прив’язаного до інших валідаторів. Наприклад, якщо учасник прив’язав деякі NOM до валідатора A до того, як пропозиція ввійшла в період голосування, а інші NOM – до валідатора B після того, як пропозиція ввійшла в період голосування, лише голосування під валідатором B буде заборонено.

#Термін голосування

Щойно пропозиція досягає MinDeposit, вона негайно переходить у Voting period. Ми визначаємо Voting period як інтервал між моментом початку голосування та моментом його закриття. Voting period завжди має бути коротшим, ніж Unbonding period, щоб запобігти подвійному голосуванню. Початкове значення Voting period становить 2 тижні.

#Набір параметрів

Набір варіантів пропозиції відноситься до набору варіантів, з яких учасник може вибрати під час голосування.

Початковий набір опцій включає такі опції:

• Yes

• No

• NoWithVeto

• Abstain

NoWithVeto вважається No, але також додає право Veto. Варіант Abstain дозволяє виборцям повідомити, що вони не мають наміру голосувати за або проти пропозиції, але погоджуються з результатами голосування.

#Кворум

Кворум визначається як мінімальний відсоток голосів, який необхідно віддати за пропозицію, щоб результат був дійсним.

#Поріг

Порогове значення визначається як мінімальна частка голосів «Yes» (за винятком голосів «Abstain»), щоб пропозиція була прийнята.

Спочатку поріг встановлено на рівні 50% із можливістю накласти вето, якщо більше 1/3 голосів (за винятком голосів «Abstain») є голосами «NoWithVeto ». Це означає, що пропозиції приймаються, якщо частка голосів «Yes» (за винятком голосів «Abstain») наприкінці періоду голосування перевищує 50% і якщо частка голосів «NoWithVeto» є нижчою за 1/3 (за винятком голосів «Abstain»).

#Спадок

Якщо делегатор не голосує, він успадковує свій голос валідатора.

• Якщо делегатор голосує перед своїм валідатором, він не успадкує голос валідатора.

• Якщо делегат проголосує після свого валідатора, він замінить свій голос валідатора своїм власним. Якщо пропозиція є терміновою, можливо, що голосування буде закрито до того, як делегати матимуть можливість відреагувати та скасувати голос свого валідатора. Це не проблема, оскільки для пропозицій потрібно більше 2/3 від загальної кількості голосів до кінця періоду голосування. Якщо більше ніж 2/3 валідаторів вступають у змову, вони все одно можуть цензурувати голоси делегатів.

#Покарання валідатора за неголосування

Зараз валідаторів не карають за непроголосування.

#Адреса управління

Пізніше ми можемо додати дозволені ключі, які можуть підписувати лише текстові повідомлення з певних модулів. Для MVP Governance address буде основною адресою валідатора, згенерованою під час створення облікового запису. Ця адреса відповідає PrivKey, відмінному від Tendermint PrivKey, який відповідає за підписання консенсусних повідомлень. Таким чином, валідаторам не потрібно підписувати транзакції керування за допомогою конфіденційного Tendermint PrivKey.

#Оновлення програмного забезпечення

Якщо пропозиції мають тип SoftwareUpgradeProposal, то вузли повинні оновити своє програмне забезпечення до нової версії, за яку проголосували. Цей процес ділиться на два етапи.

#Сигнал

Після прийняття пропозиції SoftwareUpgradeProposal очікується, що валідатори завантажать і встановлять нову версію програмного забезпечення, продовжуючи працювати з попередньою версією. Після того, як валідатор завантажить і встановить оновлення, він почне сигналізувати мережі, що він готовий до переходу, включивши ідентифікатор пропозиції в свої попередні коміти. (Примітка: підтвердження того, що ми хочемо це в попередніх комітах?)

Примітка. Існує лише один слот сигналу на попередню фіксацію. Якщо кілька пропозицій SoftwareUpgradeProposals прийнято протягом короткого періоду часу, сформується конвеєр, і вони будуть реалізовані одна за одною в тому порядку, в якому вони були прийняті.

#Перемикач

Як тільки блок містить більше 2/3 попередніх комітів, де подається сигнал про загальну пропозицію SoftwareUpgradeProposal, очікується, що всі вузли (включно з вузлами перевірки, повними вузлами без перевірки та легкими вузлами) перейдуть на нову версію програмного забезпечення.