Symbol Network: tarifas elevadas y otros problemas de configuración

Hola a todos,

Quería hacer un comentario sobre algunas cosas que hemos encontrado desde el lanzamiento que han causado confusión / frustración y de dónde creemos que proviene la causa raíz y sobre lo que hemos hecho para solucionarlo. Todo está relacionado con la configuración, no con el código o errores, lo cual es bueno, porque significa que se puede resolver y se está resolviendo.

Hay dos problemas específicos:

• Tarifas de red: se produjo debido a una configuración predeterminada incorrecta que se aplicó a la mayoría de los nodos y a todos los NGL, la cual se ha corregido y debería rectificarse en las próximas horas. Los propietarios de la comunidad deben verificar su transacciónSelectionStrategy
• Visualización de la finalidad: ocurrió debido a una configuración predeterminada incorrecta en los nodos sin voto, esto se ha solucionado y los propietarios de los nodos de la comunidad deben verificar su unfinalisedBlockDuration

Perdón por este error, fue un error genuino que se ha solucionado (ver más abajo): la comunidad realmente se dio cuenta y respondió para proteger la red antes de que NGL pudiera y mostró el poder de la descentralización en acción.

En el esquema de lanzamiento de una cadena pública, si uno o dos días de tarifas altas que se pueden aceptar o rechazar y se presenta un gráfico extraño en el explorador de bloques de los nodos sin voto no es extraño que pase y son los principales problemas que sucedieron, todavía es bastante sencillo. Pero esta parte claramente podría haber sido más leve.

Tarifas de la red

La red se implementó con un par de valores predeterminados establecidos, estos han causado un problema porque estaban presentes en Bootstrap como predeterminado por error y como resultado, eran iniciales en la mayoría de los nodos de la comunidad y todos los nodos NGL, por lo que a medida que la red se puso en marcha las tarifas comenzaron a subir. Esto fue un error y se está solucionando.

defaultDynamicFeeMultipler: 100

minFeeMultiplier: 100

transactionSelectionStrategy: maximize

El valor defaultDynamicFeeMultipler es una configuración de toda la red y se usa para ayudar a calcular la tarifa en un grupo de bloques donde el grupo contiene bloques vacíos; básicamente, si está vacío, se aplica el valor predeterminado, de lo contrario se aplica minFeeMultiplier

MinFeeMultiplier es una configuración de nodo y los operadores de nodo pueden modificarlo. Está configurado del mismo modo que la tarifa dinámica de forma predeterminada, pero los propietarios pueden ajustarlo para incluir diferentes tipos de transacciones cuando se cosecha un bloque en su nodo

La transactionSelectionStrategy se puede configurar para minimizar, maximizar o usar la más antigua. La intención era establecerlo en el más antiguo, desafortunadamente se implementó con maximizar, lo que significa que todos los nodos, incluidos los de NGL, buscaban elegir las transacciones de tarifa más alta y junto con el multiplicador, esto aumentó las tarifas.

Entonces, lo que hemos establecido ahora en los nodos NGL es lo siguiente y se implementó lentamente durante las últimas 24 horas para evitar interrumpir la finalización:

TransactionSelectionStrategy: oldest

Estamos buscando aplicar un rango de valores para minFeeMultiplier de 10 a 90, de modo que proporcionemos una columna vertebral de nodos que recojan tarifas de menor valor y las procesen, también brindan una configuración más heterogénea en toda la red.

Se está preparando un lanzamiento de Symbol Bootstrap que se lanzará mañana y luego se distribuirá en nuestros nodos, nuevamente de forma lenta para evitar interrumpir la red.

Algo muy alentador sucedió ayer en esta sección: un grupo privado de propietarios de nodos se dio cuenta de lo que estaba sucediendo y reaccionó colectivamente para establecer sus multiplicadores bajos y la estrategia de selección de transacciones en la más antigua. Reaccionaron más rápido que NGL (tenemos que tener cuidado con la finalidad y nos estábamos recuperando del lanzamiento) y utilizaron la dinámica del mercado de la cadena para contrarrestar las tarifas hasta que resolvieramos nuestro problema. Gracias especialmente a @meyns, que se apresuró a detectar esto y aconsejó a otros cómo ayudar. Esto muestra el poder de un conjunto distribuido de propietarios y la dinámica del mercado de esos entornos.

No debería haber sido necesario y nos disculpamos sin reservas por el desliz, no fue intencional. Las tarifas cobradas por NGL en las primeras 48 horas SIEMPRE irían al fondo del supernodo de todos modos, por lo que NGL tampoco se beneficia de este error de ninguna manera.

Finality

Al principio del primer día de operación, algunos de ustedes pueden haber notado que parecía que muchos nodos estaban atascados en el bloque 1 por mucho tiempo. No lo estaban, la finalidad se estaba moviendo perfectamente bien.

Lo que sucedió fue que los únicos nodos que tenian toda la información sobre las rondas de finalidad eran los del grupo de votación en ese momento, el resto espera las pruebas. Esas pruebas son recogidas / notadas por los otros nodos en función de una configuración llamada unsin finalisedBlockDuration.

La configuración en los valores predeterminados se estableció en 0, debido a que muchos de nuestros nodos son nodos de votación. Para un nodo de votación se DEBE establecer en 0. Pero para un nodo sin votación 0 significa que no verifique las pruebas hasta terminar la Época de la Finalidad (1440 bloques, 12 horas) así que todo lo que estaba sucediendo era que los nodos sin voto no podían “ver” la finalidad hasta que las Épocas terminaron.

Esto debería haberse establecido a los 5 m ó 10 m Debido a que era lo predeterminado, ya que afectaba a la mayoría de los nodos de la comunidad y a todos los que no tenían derecho a voto, por lo que en el Block Explorer parecía que había un problema.

Hemos cambiado la configuración en todos nuestros nodos y aconsejamos a un par de grupos o titulares de nodos que hagan lo mismo, también se ha cambiado en la configuración predeterminada y se incluirá en la versión de Bootstrap mañana.

Esta es una traducción al español del artículo original (en inglés) escrito por DaveH en el Foro Oficial de NEM . Traducido y editado por NEM en Español. Juntos estamos haciendo que NEM sea más fuerte y que Symbol sea más brillante.

Para más información y noticias sobre NEM, le invitamos a seguirnos en nuestras redes sociales: Facebook, Twitter e Instagram