xx Network Economic Tweaks – Deduções de Falhas em Tempo Real

Pessoa com uma calculadora

Com base no feedback da comunidade, a equipe tem uma proposta de economia e procura a comunidade para ajudar na decisão final

Um problema que veio à tona com o lançamento da rede xx MainNet é que existem alguns nós de desempenho inferior em execução na rede.

Nas encarnações anteriores da rede — AlphaNet, BetaNet e ProtoNet — esses problemas foram tratados pela equipe simplesmente desabilitando nós de baixo desempenho. Isso obviamente não é possível na MainNet que é controlada pelo nPoS.  

A comunidade vem discutindo esse assunto desde o lançamento da MainNet (você pode encontrar um tópico muito interessante no canal de bate-papo #MainNet no discórdia). Soluções envolvendo escalas móveis de penalidades, entre outras, foram propostas. No geral, é opinião da equipe 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) é atribuída uma quantidade de moedas (o mecanismo para esta decisão está descrito no xx papel de economia) e distribuído 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 o prêmio totalizar 50.000xx, e um nó específico obteve 10.000 pontos de um total de 10.000.000, eles receberão (10.000/10.000.000)×(50.000xx) = 500xx (a ser dividido entre o validador e os nomeadores) .

Mas como esses pontos são ganhos?

Os pontos são ganhos por duas coisas dentro da rede xx: fazer blocos e executar rodadas cMix. É dentro do mecanismo de execução de rodadas cMix que está o esquema de incentivo.

Sempre que uma rodada é concluída, todos os 5 nós da equipe ganham 10 pontos, enquanto quando uma rodada falha durante a fase em tempo real, os nós perdem 20 pontos. Esta perda de pontos é para desincentivar o mau comportamento. A princípio, isso parece muito injusto – se uma rodada falhar devido a um nó, por que cada nó deveria ser penalizado?

Existem duas razões:

A primeira é que sob BFT (Byzantine Fault Tolerance) não é possível determinar quem está com falha dentro do protocolo cMix. Isso 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.

Essa solução funciona, com a exceção de que deve atingir uma taxa de falha na qual os nós devem perder todos os seus ganhos. Dado que queremos um sistema com confiabilidade muito alta, queremos atingir um número muito maior que 50%.

Em geral, a equação que relaciona a taxa de falha alvo e os pontos é a seguinte:

Dado que o sucesso de pontos é sempre 10, isso nos dá:

Isso também é uma aproximação porque não leva em consideração os multiplicadores regionais, quanto tempo leva para os nós se recuperarem de rodadas com falha, nem como diferentes configurações de hardware e internet de nós podem afetar os tempos de rodada. Mas é suficiente para análise neste momento.

A grande questão que permanece é: qual deve ser a “falha direcionada” apropriada. Em geral, pode ser maior do que o esperado porque os pontos e, portanto, os ganhos ainda diminuem substancialmente quando um nó tem altas taxas de falha que não o atendem.

Nas últimas 12 horas, as maiores taxas 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 0,35%). 

Dados esses dados, a equipe acredita que devemos passar da meta 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 da comunidade nos próximos dias e revisitaremos com base na resposta em 6 de dezembro de 2021

Há também uma solução temporária secundária na qual a equipe está trabalhando. A falha final das soluções econômicas é que elas podem levar tempo, o que não é ótimo quando as mensagens estão sendo descartadas ativamente pelo xx messenger e outros usuários do xxDk. Como resultado, a equipe publicará uma lista de operadores de nós com baixo desempenho que os usuários do xxDK podem optar por não enviar mensagens em rodadas que contenham esses nós. Também será possível que os usuários do xxDK optem por outras listas selecionadas separadamente.

A equipe também procurará tornar o multiplicador de equipe contingente ao desempenho mínimo, com mais informações em breve.

Popular