Com base no feedback da comunidade, a equipe tem uma proposta de economia, e está procurando a comunidade para ajudar na decisão final
Um problema que surgiu com o lançamento do xx network MainNet é que há alguns nós de menor desempenho rodando na rede.
Nas encarnações anteriores da rede - AlphaNet, BetaNet e ProtoNet - estas questões eram tratadas pela equipe simplesmente desativando os nós de mau desempenho. Isto obviamente não é possível no MainNet que é controlado pelo nPoS.
A comunidade tem discutido esta questão desde o lançamento do MainNet (você pode encontrar um tópico muito atencioso no canal de conversa do #MainNet no discórdia). Soluções envolvendo escalas deslizantes de penalidades, entre outras, foram propostas. Em geral, a equipe é de opinião que um ajuste na solução existente, juntamente com uma modificação do lado do cliente, é a abordagem correta.
Para entender a solução atual, alguns detalhes da economia precisarão ser revistos. Em cada época (período de 24 horas) uma quantidade de moedas é concedida (o mecanismo para esta decisão é descrito no xx papel de economia) e distribuídos entre todos os nós. A parte dessas moedas concedida a um determinado nó é igual à sua parte do total de moedas ganhas. Por exemplo, se em uma época a premiação totalizar 50.000xx, e um nó específico receber 10.000 pontos de um total de 10.000.000, eles receberão (10.000/10.000.000)×(50.000xx) = 500xx (a serem divididos entre o validador e os nominadores).
Mas como esses pontos são conquistados?
Os pontos são ganhos por duas coisas dentro do xx network: fazer blocos e executar rodadas de cMix. É dentro do mecanismo de rodadas do cMix que se encontra o esquema de incentivo.
Sempre que uma rodada é concluída, todos os 5 nós da equipe ganham 10 pontos, enquanto que quando uma rodada falha durante a fase de tempo real, os nós perdem 20 pontos. Esta perda de pontos é para desincentivar o mau comportamento. No início isto parece muito injusto - se uma rodada falha devido a um nó, por que cada nó deve ser penalizado?
Há duas razões:
A primeira é que sob o BFT (Byzantine Fault Tolerance) não é possível determinar quem está em falta dentro do protocolo cMix. Isto significa que não é possível provar qual nó deve perder pontos.
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.
Esta solução funciona, com a exceção de que ela deve visar uma taxa de falha na qual os nós devem perder todos os seus ganhos. Dado que queremos um sistema com uma confiabilidade muito alta, queremos atingir um número muito superior a 50%.
Em geral, a equação relativa à taxa de falha visada e aos pontos é a seguinte:
Dado que os pontos de sucesso são sempre 10, isto nos dá 10:
Isto também é uma aproximação porque não leva em conta os multiplicadores regionais, quanto tempo leva para que os nós se recuperem de rodadas fracassadas, nem como diferentes configurações de hardware e de Internet podem ter impacto em tempos redondos. Mas é suficiente para análise neste momento.
A grande questão que permanece é, qual deve ser o "fracasso orientado" apropriado. Em geral, ela pode ser maior do que se espera porque os pontos, e portanto os ganhos, ainda caem substancialmente quando um nó tem altas taxas de falha que não a cumprem.
Nas últimas 12 horas, as taxas mais altas de falhas em tempo real são as seguintes:
27.22%, 3.79%, 3.58%, 1.64%, 1.19%
Com uma taxa média de falhas de 0,5% (mediana de 0,35%).
Dados estes dados, a equipe acredita que devemos passar de uma taxa de falha de 33% para 5%, o que traria a dedução de pontos por falha em tempo real para 190.
Gostaríamos de abrir esta questão para discussão comunitária nos próximos dias e revisitaremos o assunto com base na resposta de 6 de dezembro de 2021.
Há também uma solução de parada secundária na qual a equipe está trabalhando. A última falha com soluções econômicas é que elas podem levar tempo, o que não é ótimo quando as mensagens estão sendo ativamente descartadas pelo xx messenger e outros usuários do xxDk. Como resultado, a equipe publicará uma lista de operadores de nós atualmente com mau desempenho que os usuários do xxDK podem optar opcionalmente por não enviar mensagens em rodadas que contenham esses nós. Também será possível para os usuários do xxDK optarem por outras listas com curadoria separada.
A equipe também estará procurando fazer com que o multiplicador da equipe seja dependente do desempenho mínimo, com mais informações em breve.
