На основі відгуків громади команда має пропозицію щодо економіки, і шукає допомоги громади у прийнятті остаточного рішення.
Проблема, яка виявилася з запуском 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. Це означає, що неможливо довести, який саме вузол повинен втратити бали.
The second is that in the aggregate, other nodes are not penalized. For example, imagine a network with 15 nodes and 5 node teams where all nodes except for one cause 0% of rounds to fail, with one failing 50%. What will happen is that given enough rounds, all good nodes will work with the bad node equally and because points are distributed based upon the total ratio of points, not total points, all “good” nodes will get the same number of xx coins, while the bad node will be penalized. In the above case, a node will be in a team with the bad node 1/3rd of the time. It has a 50% failure rate, so all nodes will have an aggregate 16.667% failure rate. Assuming 100,000 rounds, and each participates in 1/3rd, that means that with the current economics, they will earn 10×100,000×⅓×(1-%16.667) = 277,778 points, and lose 20×100,000×⅓×(%16.667) = 111,111 points, making a total of 166,667 points. While in the same scenario, the offending node will earn 10×100,000×⅓×(%50) = 166,667 and lose 20×100,000×⅓×(%50) = 333,333 points, making a total of -166,667. Points cannot go negative, so the offending nodes get 0 points, and as a result all rewards are split between the other 14 good nodes evenly – as if the offending node was never there.
Це рішення дійсно працює, за винятком того, що воно повинно орієнтуватися на частоту відмов, при якій вузли повинні втратити весь свій прибуток. Враховуючи, що нам потрібна система з дуже високою надійністю, ми хочемо націлитися на число набагато вище, ніж 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 також зможуть обирати інші, окремо куровані списки.
Команда також розглядатиме питання про те, щоб мультиплікатор команди залежав від мінімальної продуктивності, і найближчим часом з'явиться додаткова інформація.
