xx network Экономические изменения - вычеты за неудачи в реальном времени

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

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

Проблема, которая стала известна после запуска 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. Это означает, что невозможно доказать, какой узел должен потерять очки.

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

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

Популярные