xx network Economic Tweaks — вычеты из-за сбоев в реальном времени

Человек с калькулятором

Основываясь на отзывах сообщества, у команды есть предложение по экономике, и она ищет сообщество, которое поможет принять окончательное решение.

Проблема, которая обнаружилась с запуском сети xx 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: создание блоков и запуск раундов 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 и другими пользователями xxDk. В результате команда опубликует список плохо работающих в настоящее время операторов узлов, которым пользователи xxDK могут при желании запретить отправку сообщений в раундах, содержащих эти узлы. Пользователи xxDK также смогут участвовать в других, отдельно курируемых списках.

Команда также рассмотрит вопрос о том, чтобы множитель команды зависел от минимальной производительности, и скоро появится дополнительная информация.

Популярный