Ajustes económicos de la red xx: deducciones por fallas en tiempo real

persona con una calculadora

Con base en los comentarios de la comunidad, el equipo tiene una propuesta económica y está buscando a la comunidad para ayudar en la decisión final.

Un problema que salió a la luz con el lanzamiento de MainNet de la red xx es que hay algunos nodos de bajo rendimiento que se ejecutan en la red.

En las encarnaciones anteriores de la red (AlphaNet, BetaNet y ProtoNet), el equipo manejó estos problemas simplemente deshabilitando los nodos de bajo rendimiento. Obviamente, esto no es posible en MainNet, que está controlado por nPoS.  

La comunidad ha estado discutiendo este problema desde el lanzamiento de MainNet (puede encontrar un hilo muy reflexivo en el canal de chat #MainNet-chat en el discordia). Se han propuesto soluciones que involucran escalas móviles de penas, entre otras. En general, la opinión del equipo es que un ajuste a la solución existente, junto con una modificación del lado del cliente, es el enfoque correcto.

Para comprender la solución actual, será necesario revisar algunos detalles económicos. En cada época (período de 24 horas) se otorga una cantidad de monedas (el mecanismo para esta decisión se describe en el xx documento de economía) y distribuida entre todos los nodos. La porción de estas monedas otorgadas a un nodo dado es igual a su porción del total de monedas ganadas. Por ejemplo, si en una época el premio asciende a 50 000xx y un nodo específico obtuvo 10 000 puntos de un total de 10 000 000, obtendrá (10 000/10 000 000) × (50 000xx) = 500xx (a dividir entre el validador y los nominadores) .

Pero, ¿cómo se ganan estos puntos?

Los puntos se ganan por dos cosas dentro de la red xx: hacer bloques y ejecutar rondas de cMix. Es dentro del mecanismo para ejecutar rondas cMix donde se encuentra el esquema de incentivación.

Cada vez que se completa una ronda, los 5 nodos del equipo ganan 10 puntos, mientras que cuando falla una ronda durante la fase en 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 falla debido a un nodo, ¿por qué deberían penalizarse todos los nodos?

Hay dos razones:

La primera es que bajo BFT (Byzantine Fault Tolerance) no es posible determinar quién tiene la culpa dentro del protocolo cMix. Esto significa que no es posible probar 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 falla en la que los nodos deberían perder todas sus ganancias. Dado que queremos un sistema con una confiabilidad muy alta, queremos apuntar a un número mucho más alto que 50%.

En general, la ecuación que relaciona la tasa de fracaso objetivo y los puntos es la siguiente:

Dado que los puntos de éxito siempre son 10, esto nos da:

Esta también es una aproximación porque no tiene en cuenta los multiplicadores regionales, el tiempo que tardan los nodos en recuperarse de rondas fallidas, ni cómo las diferentes configuraciones de hardware e Internet de los nodos pueden afectar los tiempos de ronda. Pero es suficiente para el análisis en este momento.

La gran pregunta que queda es cuál debería ser la "falla dirigida" apropiada. En general, puede ser más alto de lo que uno espera porque los puntos y, por lo tanto, las ganancias, aún disminuyen sustancialmente cuando un nodo tiene altas tasas de fallas que no lo cumplen.

En las últimas 12 horas, las tasas más altas de fallas en tiempo real son las siguientes:

27.22%, 3.79%, 3.58%, 1.64%, 1.19%

Con una tasa de falla promedio de 0.5% (mediana de 0.35%). 

Dados estos datos, el equipo cree que deberíamos pasar de apuntar a una tasa de fallas de 33% a 5%, lo que llevaría la deducción de puntos por falla en tiempo real a 190.  

Nos gustaría abrir este tema para el debate 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 provisional secundaria en la que está trabajando el equipo. El último defecto de las soluciones económicas es que pueden llevar tiempo, lo cual no es muy bueno cuando xx messenger y otros usuarios de xxDk envían mensajes activamente. Como resultado, el equipo publicará una lista de operadores de nodos que actualmente tienen un rendimiento deficiente y que los usuarios de xxDK pueden optar por no enviar mensajes en rondas que contengan esos nodos. También será posible que los usuarios de xxDK opten por otras listas seleccionadas por separado.

El equipo también buscará hacer que el multiplicador del equipo dependa del rendimiento mínimo, y próximamente habrá más información.

Popular