На основі відгуків громади команда має пропозицію щодо економіки, і шукає допомоги громади у прийнятті остаточного рішення.
Проблема, яка виявилася з запуском xx network MainNet, полягає в тому, що в мережі працюють деякі вузли з низькою продуктивністю.
У попередніх втіленнях мережі - AlphaNet, BetaNet і ProtoNet - ці проблеми вирішувалися командою шляхом простого відключення погано працюючих вузлів. Очевидно, що це неможливо в MainNet, яка контролюється nPoS.
Спільнота обговорює це питання з моменту запуску 1ТП12Т (дуже вдумливу тему можна знайти в чаті 1ТП21Т1ТП12Т на каналі #MainNet-chat на розбрат). Були запропоновані рішення, що включають, серед іншого, ковзаючу шкалу штрафів. Загалом, на думку команди, доопрацювання існуючого рішення разом з модифікацією на стороні клієнта є правильним підходом.
Щоб зрозуміти поточне рішення, необхідно розглянути деякі деталі економіки. У кожну епоху (24-годинний період) присуджується певна кількість монет (механізм цього рішення описано в xx економічна газета) і розподіляється між усіма вузлами. Частка цих монет, що присуджується конкретному вузлу, дорівнює його частці в загальній кількості зароблених монет. Наприклад, якщо в епоху винагорода становить 50 000хх, а конкретний вузол отримав 10 000 балів із загальних 10 000 000, він отримає (10 000/10 000 000)×(50 000хх) = 500хх (які будуть розділені між валідатором і номінаторами).
Але як заробляються ці бали?
Бали в рамках xx network заробляються за дві речі: створення блоків та виконання раундів cMix. Саме в механізмі проходження раундів cMix і полягає схема стимулювання.
Кожного разу, коли раунд завершується, всі 5 вузлів в команді заробляють 10 балів, тоді як при невдалому завершенні раунду під час фази реального часу вузли втрачають 20 балів. Ця втрата балів має дестимулювати погану поведінку. Спочатку це здається дуже несправедливим - якщо раунд провалився через один вузол, чому кожен вузол повинен бути покараний?
Причин дві:
Перша полягає в тому, що за протоколом BFT (Byzantine Fault Tolerance - візантійська відмовостійкість) неможливо визначити, хто саме винен в роботі протоколу cMix. Це означає, що неможливо довести, який саме вузол повинен втратити бали.
Другий полягає в тому, що в сукупності інші вузли не будуть покарані. Наприклад, уявіть собі мережу з 15 вузлів і 5 команд, де всі вузли, окрім одного, не виконали 0% раундів, причому один з них не виконав 50%. За умови достатньої кількості раундів всі хороші вузли будуть працювати з поганим вузлом однаково, і оскільки бали розподіляються на основі загального співвідношення балів, а не загальної кількості балів, всі "хороші" вузли отримають однакову кількість xx coin, в той час як поганий вузол буде оштрафований. У наведеному вище прикладі вузол буде в команді з поганим вузлом 1/3 часу. Він має частоту відмов 50%, тому всі вузли матимуть сумарну частоту відмов 16.667%. Якщо припустити, що буде 100 000 раундів, і кожен братиме участь у 1/3, це означає, що за поточної економіки вони зароблять 10×100 000×⅓×(1-.667) = 277 778 очок, і втратять 20×100 000×⅓×(.667) = 111 111 очок, що в сумі складе 166 667 очок. У цьому ж сценарії вузол-порушник заробить 10×100,000×⅓×() = 166,667 очок і втратить 20×100,000×⅓×() = 333,333 очок, тобто загалом -166,667. Кількість балів не може бути від'ємною, тому вузли-порушники отримують 0 балів, і в результаті вся винагорода розподіляється між іншими 14 хорошими вузлами порівну - так, ніби вузла-порушника там ніколи не було.
Це рішення дійсно працює, за винятком того, що воно повинно орієнтуватися на частоту відмов, при якій вузли повинні втратити весь свій прибуток. Враховуючи, що нам потрібна система з дуже високою надійністю, ми хочемо націлитися на число набагато вище, ніж 50%.
Загалом, рівняння, що пов'язує цільовий рівень відмов та бали, виглядає наступним чином:
Враховуючи, що балів успіху завжди 10, це нам дає:
Це також наближений показник, оскільки він не враховує регіональні мультиплікатори, час, необхідний вузлам для відновлення після невдалих раундів, а також те, як різні апаратні та інтернет-конфігурації вузлів можуть впливати на час раундів. Але цього достатньо для аналізу на даний момент.
Великим питанням, яке залишається, є те, якою має бути відповідна "цільова відмова". Загалом, він може бути вищим, ніж очікується, оскільки бали, а отже, і заробіток, все одно суттєво знижуються, коли вузол має високий рівень відмов, що не відповідає йому.
За останні 12 годин найбільші показники відмов у реальному часі зафіксовані наступним чином:
27.22%, 3.79%, 3.58%, 1.64%, 1.19%
З середньою частотою відмов 0,5% (медіана 0,35%).
Враховуючи ці дані, команда вважає, що ми повинні перейти від цільового показника відмов 33% до 5%, що призведе до відрахування балів за кожну відмову в реальному часі до 190.
Ми хотіли б відкрити це питання для громадського обговорення протягом наступних кількох днів і повернемося до нього на основі отриманих відповідей 6 грудня 2021 р.
Існує також вторинне рішення, над яким працює команда. Основним недоліком економічних рішень є те, що вони можуть зайняти багато часу, що не дуже добре, коли повідомлення активно надсилаються xx messenger та іншими користувачами xxDk. Як результат, команда опублікує список операторів вузлів, які в даний час погано працюють, і користувачі xxDK можуть за бажанням не надсилати повідомлення в раундах, які містять ці вузли. Користувачі xxDK також зможуть обирати інші, окремо куровані списки.
Команда також розглядатиме питання про те, щоб мультиплікатор команди залежав від мінімальної продуктивності, і найближчим часом з'явиться додаткова інформація.
