Mi primera reacción al leer el consenso de SA fue: ¿cómo se obtiene el número 1000 DUSK? El whitepaper solo da el resultado, no el proceso de deducción. Así que seguí sus parámetros para reconstruirlo.
Establece un epoch de 2160 bloques. Según la velocidad de producción actual de Dusk, aproximadamente 6 horas conforman un epoch. Luego da una fórmula de periodo de madurez: M = 2 × epoch - (height mod epoch). Es decir, si haces staking de una cantidad de DUSK, tienes que esperar desde casi medio epoch hasta un epoch completo para que realmente empiece tu participación.
Hay algo interesante en este diseño: alinea el tiempo de activación de todos los nuevos stakes con el límite del epoch. No se activa “en cuanto entras”, sino que todos se activan colectivamente en el mismo punto. Supongo que el objetivo es que el sorteo determinista del algoritmo DS tenga una instantánea estable del pool de staking. Si entran y se activan en cualquier momento, entonces el conjunto de candidatos provisioner de cada bloque cambia; así la asignación determinista se vuelve difícil de implementar $DUSK
¿Y el 1000 DUSK en sí? Yo calculé que, si el umbral se fija en 100, la cantidad de provisioners se dispararía. Con 64 slots compitiendo más intensamente en cada epoch, pero la cantidad de staking por nodo sería demasiado baja; la seguridad de la red podría incluso diluirse. Si se fija en 10000, entonces el público minorista básicamente no podría entrar: los provisioners se reducirían a unos pocos nodos grandes, y la descentralización se vería afectada en consecuencia. @Dusk
El número 1000 queda en medio. Revisé los parámetros de otras cadenas PoS: el umbral de Dusk no es particularmente alto, pero tampoco es bajo. Es como si dijera: no quiero que ejecutes un nodo con solo una propina cualquiera, pero tampoco quiero que necesariamente tengas que ser un “ballena” para participar.
Sin embargo, todavía tengo una pregunta que no termino de entender. El whitepaper no especifica el rango objetivo del número total de provisioners, ni tampoco qué proporción de intensidad de competencia entre los 64 slots sería la óptima. Sin esos datos, en realidad no puedo determinar si 1000 es adecuado. Tal vez su razonabilidad solo pueda verificarse con datos reales después del lanzamiento en la red principal. #dusk
Establece un epoch de 2160 bloques. Según la velocidad de producción actual de Dusk, aproximadamente 6 horas conforman un epoch. Luego da una fórmula de periodo de madurez: M = 2 × epoch - (height mod epoch). Es decir, si haces staking de una cantidad de DUSK, tienes que esperar desde casi medio epoch hasta un epoch completo para que realmente empiece tu participación.
Hay algo interesante en este diseño: alinea el tiempo de activación de todos los nuevos stakes con el límite del epoch. No se activa “en cuanto entras”, sino que todos se activan colectivamente en el mismo punto. Supongo que el objetivo es que el sorteo determinista del algoritmo DS tenga una instantánea estable del pool de staking. Si entran y se activan en cualquier momento, entonces el conjunto de candidatos provisioner de cada bloque cambia; así la asignación determinista se vuelve difícil de implementar $DUSK
¿Y el 1000 DUSK en sí? Yo calculé que, si el umbral se fija en 100, la cantidad de provisioners se dispararía. Con 64 slots compitiendo más intensamente en cada epoch, pero la cantidad de staking por nodo sería demasiado baja; la seguridad de la red podría incluso diluirse. Si se fija en 10000, entonces el público minorista básicamente no podría entrar: los provisioners se reducirían a unos pocos nodos grandes, y la descentralización se vería afectada en consecuencia. @Dusk
El número 1000 queda en medio. Revisé los parámetros de otras cadenas PoS: el umbral de Dusk no es particularmente alto, pero tampoco es bajo. Es como si dijera: no quiero que ejecutes un nodo con solo una propina cualquiera, pero tampoco quiero que necesariamente tengas que ser un “ballena” para participar.
Sin embargo, todavía tengo una pregunta que no termino de entender. El whitepaper no especifica el rango objetivo del número total de provisioners, ni tampoco qué proporción de intensidad de competencia entre los 64 slots sería la óptima. Sin esos datos, en realidad no puedo determinar si 1000 es adecuado. Tal vez su razonabilidad solo pueda verificarse con datos reales después del lanzamiento en la red principal. #dusk