Basándose en los comentarios de la comunidad, el equipo tiene una propuesta de economía, y está buscando que la comunidad ayude en la decisión final
Un problema que ha salido a la luz con el lanzamiento del xx network MainNet es que hay algunos nodos de menor rendimiento funcionando en la red.
En las anteriores encarnaciones de la red -AlphaNet, BetaNet y ProtoNet- el equipo se encargaba de estos problemas simplemente desactivando los nodos de bajo rendimiento. Obviamente, esto no es posible en MainNet, que está controlado por nPoS.
La comunidad ha estado discutiendo este tema desde el lanzamiento de MainNet (puede encontrar un hilo muy reflexivo en el canal de chat #MainNet en el discordia). Se han propuesto soluciones que incluyen escalas de penalización, entre otras. En general, el equipo opina que un ajuste de la solución existente, junto con una modificación del lado del cliente, es el enfoque correcto.
Para entender la solución actual, habrá que revisar algunos detalles de la economía. En cada época (periodo de 24 horas) se adjudica una cantidad de monedas (el mecanismo de esta decisión se describe en el xx documento de economía) y se distribuye entre todos los nodos. La parte de estas monedas concedida a un nodo determinado es igual a su parte del total de monedas ganadas. Por ejemplo, si en una época el premio asciende a 50.000xx, y un nodo concreto obtuvo 10.000 puntos de un total de 10.000.000, recibirá (10.000/10.000.000)×(50.000xx) = 500xx (a repartir entre el validador y los nominadores).
Pero, ¿cómo se obtienen estos puntos?
Los puntos se obtienen por dos cosas dentro del xx network: hacer bloques y correr rondas de cMix. El mecanismo de ejecución de las rondas de cMix es el que permite incentivar el juego.
Cada vez que se completa una ronda, los 5 nodos del equipo ganan 10 puntos, mientras que cuando una ronda falla durante la fase de tiempo real los nodos pierden 20 puntos. Esta pérdida de puntos es para desincentivar el mal comportamiento. Al principio esto parece muy injusto: si una ronda fracasa por culpa de un nodo, ¿por qué deberían ser penalizados todos los nodos?
Hay dos razones:
La primera es que bajo BFT (Byzantine Fault Tolerance) no es posible determinar quién está en falta dentro del protocolo cMix. Esto significa que no es posible demostrar qué nodo debe perder puntos.
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 solución funciona, con la excepción de que debe apuntar a una tasa de fallos en la que los nodos deberían perder todas sus ganancias. Dado que queremos un sistema con una fiabilidad muy alta, queremos apuntar a un número mucho mayor que 50%.
En general, la ecuación que relaciona la tasa de fracaso prevista y los puntos es la siguiente:
Dado que el éxito de los puntos es siempre 10, esto nos da:
Esto también es una aproximación porque no tiene en cuenta los multiplicadores regionales, el tiempo que tardan los nodos en recuperarse de las rondas fallidas, ni cómo las diferentes configuraciones de hardware e Internet de los nodos pueden afectar a los tiempos de las rondas. Pero es suficiente para el análisis en este momento.
La gran pregunta que queda es cuál debe ser el "objetivo de fracaso" adecuado. En general, puede ser más alto de lo que uno espera porque los puntos, y por tanto las ganancias, siguen bajando sustancialmente cuando un nodo tiene altos índices de fracaso que no lo cumplen.
En las últimas 12 horas, los mayores índices de fallos en tiempo real son los siguientes:
27.22%, 3.79%, 3.58%, 1.64%, 1.19%
Con una tasa media de fallos de 0,5% (mediana de 0,35%).
A la vista de estos datos, el equipo cree que deberíamos pasar de un objetivo de tasa de fallos de 33% a 5%, lo que situaría la deducción de puntos por fallo en tiempo real en 190.
Nos gustaría abrir este tema a la discusión de la comunidad en los próximos días y lo revisaremos en función de la respuesta del 6 de diciembre de 2021
También hay una solución secundaria provisional en la que el equipo está trabajando. El último defecto de las soluciones económicas es que pueden llevar tiempo, lo que no es bueno cuando los mensajes están siendo activamente abandonados por el xx messenger y otros usuarios del xxDk. Como resultado, el equipo publicará una lista de operadores de nodos que actualmente tienen un bajo rendimiento y los usuarios de la xxDK podrán optar por no enviar mensajes en las rondas que contengan esos nodos. Los usuarios de xxDK también podrán optar por otras listas seleccionadas por separado.
El equipo también va a estudiar la posibilidad de que el multiplicador del equipo dependa del rendimiento mínimo, y pronto habrá más información al respecto.
