Después del Magreb, empecé a hurgar en las notas del consenso de Dusk y seguí volviendo al silencioso vacío estadístico que sigue ahí. @Dusk
El diseño de Compromiso (Attestation) Sencillo (Succinct) busca una finalización determinista. Una vez que un bloque es ratificado, se trata como final bajo condiciones normales, y el protocolo indica que no debería haber reorgs visibles para el usuario en la operación ordinaria.
Aun así, pueden aparecer bifurcaciones cuando los retrasos o la congestión permiten que más de una iteración llegue al consenso en la misma ronda. La regla oficial es sencilla: mantener siempre el bloque de la iteración más baja y descartar las demás. También existe la finalización continua — un bloque se acepta primero, puede seguir siendo reemplazado mientras solo está atestiguado, y se vuelve inmutable únicamente después de que los bloques posteriores lo confirmen.
El punto estadístico es el que se quedó. Ver 3 bifurcaciones en 1.000 ensayos se ve igual que 300 bifurcaciones en 100.000 ensayos si solo miras la tasa bruta. Sin el error estándar y los intervalos de confianza del 95% no puedes saber si la estimación es estable o solo ruido. Las pruebas adecuadas requieren tamaños de muestra grandes, como los perfiles aleatorios de retraso de validador sugeridos (100.000) y múltiples patrones de latencia, no un único modelo de red “amigable”.
La documentación oficial describe las reglas de bifurcación y afirma una finalización de baja latencia. No publican resultados a gran escala con intervalos de confianza bajo retrasos sesgados o poco amistosos.
Ese vacío estadístico fue más difícil de ignorar de lo que esperaba. Una tasa baja observada de bifurcaciones es útil. Lo que realmente genera confianza es saber cuánta incertidumbre hay en esa tasa cuando la red se pone caótica. Todavía masticando la idea de si esa capa estadística aparecerá en los materiales públicos.
#dusk $DUSK
El diseño de Compromiso (Attestation) Sencillo (Succinct) busca una finalización determinista. Una vez que un bloque es ratificado, se trata como final bajo condiciones normales, y el protocolo indica que no debería haber reorgs visibles para el usuario en la operación ordinaria.
Aun así, pueden aparecer bifurcaciones cuando los retrasos o la congestión permiten que más de una iteración llegue al consenso en la misma ronda. La regla oficial es sencilla: mantener siempre el bloque de la iteración más baja y descartar las demás. También existe la finalización continua — un bloque se acepta primero, puede seguir siendo reemplazado mientras solo está atestiguado, y se vuelve inmutable únicamente después de que los bloques posteriores lo confirmen.
El punto estadístico es el que se quedó. Ver 3 bifurcaciones en 1.000 ensayos se ve igual que 300 bifurcaciones en 100.000 ensayos si solo miras la tasa bruta. Sin el error estándar y los intervalos de confianza del 95% no puedes saber si la estimación es estable o solo ruido. Las pruebas adecuadas requieren tamaños de muestra grandes, como los perfiles aleatorios de retraso de validador sugeridos (100.000) y múltiples patrones de latencia, no un único modelo de red “amigable”.
La documentación oficial describe las reglas de bifurcación y afirma una finalización de baja latencia. No publican resultados a gran escala con intervalos de confianza bajo retrasos sesgados o poco amistosos.
Ese vacío estadístico fue más difícil de ignorar de lo que esperaba. Una tasa baja observada de bifurcaciones es útil. Lo que realmente genera confianza es saber cuánta incertidumbre hay en esa tasa cuando la red se pone caótica. Todavía masticando la idea de si esa capa estadística aparecerá en los materiales públicos.
#dusk $DUSK