xx network Ajustes económicos - Deducción de fallos en tiempo real

Persona con una calculadora

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.

La segunda es que, en conjunto, los demás nodos no son penalizados. Por ejemplo, imaginemos una red con 15 nodos y equipos de 5 nodos en la que todos los nodos excepto uno hacen fallar 0% de rondas, y uno falla 50%. Lo que ocurrirá es que, dadas suficientes rondas, todos los nodos buenos trabajarán con el nodo malo por igual y, dado que los puntos se distribuyen en base a la proporción total de puntos, no a los puntos totales, todos los nodos "buenos" obtendrán el mismo número de xx coin, mientras que el nodo malo será penalizado. En el caso anterior, un nodo estará en un equipo con el nodo malo 1/3 del tiempo. Tiene una tasa de fallos de 50%, por lo que todos los nodos tendrán una tasa de fallos agregada de 16,667%. Suponiendo 100.000 rondas, y que cada uno participa en 1/3, eso significa que con la economía actual, ganarán 10×100.000×⅓×(1-.667) = 277.778 puntos, y perderán 20×100.000×⅓×(.667) = 111.111 puntos, lo que hace un total de 166.667 puntos. Mientras que en el mismo escenario, el nodo infractor ganará 10×100.000×⅓×() = 166.667 y perderá 20×100.000×⅓×() = 333.333 puntos, lo que hace un total de -166.667. Los puntos no pueden ser negativos, por lo que los nodos infractores obtienen 0 puntos, y como resultado todas las recompensas se reparten entre los otros 14 nodos buenos por igual - como si el nodo infractor nunca hubiera estado allí.

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.

Popular