xx Network Economic Tweaks – Відрахування відмов у реальному часі

Людина з калькулятором

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

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

У попередніх інкарнаціях мережі — AlphaNet, BetaNet і ProtoNet — ці проблеми вирішувалися командою шляхом простого відключення вузлів із поганою продуктивністю. Це, очевидно, неможливо в MainNet, яка контролюється nPoS.  

Спільнота обговорює це питання з моменту запуску MainNet (ви можете знайти дуже продуману тему в каналі чату #MainNet на розбрат). Запропоновано, серед іншого, рішення, що включають ковзну шкалу штрафів. Загалом, команда вважає, що зміна існуючого рішення разом із модифікацією на стороні клієнта є правильним підходом.

Щоб зрозуміти поточне рішення, потрібно буде переглянути деякі деталі економіки. У кожну епоху (24-годинний період) присуджується певна кількість монет (механізм цього рішення описано в xx економічний документ) і розподіляється між усіма вузлами. Частка цих монет, наданих даному вузлу, дорівнює їх частці від загальної кількості зароблених монет. Наприклад, якщо в епоху нагорода становить 50 000xx, а певний вузол отримав 10 000 балів із загальних 10 000 000, вони отримають (10 000/10 000 000)×(50 000xx) = 500splitxx між дійсним номінатором і номінатором. .

Але як заробляються ці бали?

Очки заробляються за дві речі в мережі xx: створення блоків і виконання раундів cMix. Схема стимулювання полягає в механізмі виконання раундів cMix.

Щоразу, коли раунд завершується, всі 5 вузлів у команді отримують 10 очок, а коли раунд не вдається під час фази реального часу, вузли втрачають 20 очок. Ця втрата балів має демотивувати погану поведінку. Спочатку це здається дуже несправедливим – якщо раунд зазнає невдачі через один вузол, чому кожен вузол повинен бути оштрафований?

Є дві причини:

По-перше, за BFT (Візантійська відмовостійкість) неможливо визначити, хто винен у протоколі 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 месенджер та інші користувачі xxDk. В результаті команда опублікує список операторів вузлів, які зараз погано працюють, і користувачі xxDK можуть за бажанням відмовитися від надсилання повідомлень під час раундів, які містять ці вузли. Користувачі xxDK також зможуть увімкнути інші, окремо керовані списки.

Команда також розгляне питання, щоб множник команди залежав від мінімальної продуктивності. Додаткова інформація буде незабаром.

Популярний