Основываясь на отзывах сообщества, команда разработала предложение по экономике и просит сообщество помочь в принятии окончательного решения
Проблема, которая стала известна после запуска xx network MainNet, заключается в том, что в сети работают некоторые узлы с более низкой производительностью.
В предыдущих воплощениях сети - AlphaNet, BetaNet и ProtoNet - эти проблемы решались командой путем простого отключения узлов с низкой производительностью. Это, очевидно, невозможно в MainNet, которая контролируется nPoS.
Сообщество обсуждает этот вопрос с момента запуска MainNet (вы можете найти очень содержательную тему в чат-канале #MainNet на дискорд). Среди прочих были предложены решения, включающие скользящую шкалу штрафов. В целом, по мнению команды, правильным подходом является внесение изменений в существующее решение, а также модификация на стороне клиента.
Чтобы понять текущее решение, необходимо рассмотреть некоторые детали экономики. В каждую эпоху (24-часовой период) начисляется определенное количество монет (механизм принятия этого решения описан в разделе реферат по экономике xx века) и распределяются между всеми узлами. Часть этих монет, присуждаемая данному узлу, равна его доле в общем количестве заработанных монет. Например, если в эпоху награда составляет 50 000xx, а конкретный узел получил 10 000 очков из общего количества 10 000 000, он получит (10 000/10 000 000)×(50 000xx) = 500xx (которые будут разделены между валидатором и номинантами).
Но как зарабатываются эти баллы?
Очки зарабатываются за две вещи в 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 также смогут выбрать другие, отдельно курируемые списки.
Команда также рассмотрит возможность сделать командный множитель зависящим от минимальных показателей, дополнительная информация появится в ближайшее время.
