Je revenais sans cesse à une chose en testant le comportement de la fourche du fork de DUSK Network : le nombre de forks lui-même m’en dit moins que la confiance derrière ce nombre. @Dusk
Trois forks sur 1 000 essais ressemble à 300 forks sur 100 000 essais. Même taux observé. Des preuves très différentes.
C’est pourquoi je ne m’arrêterais pas à un seul résultat de simulation.
Pour DUSK Network, l’étape 1 doit générer 100 000 profils aléatoires de délais de validateurs. L’étape 2 doit rejouer des conditions de propositions conflictuelles sur plusieurs distributions de latence, pas sur un seul modèle de réseau pratique. Ensuite, l’étape 3 convertit ces comptages de forks en probabilité, écart-type (erreur standard) et intervalles de confiance à 95 %.
Le problème caché n’est pas l’activité versus l’inactivité. Il s’agit de la résilience du protocole versus l’illusion statistique.
Les forks rares restent-ils rares quand les délais des validateurs deviennent biaisés ? Une seule distribution de latence domine-t-elle les échecs ? L’intervalle de confiance se resserre-t-il suffisamment pour faire confiance à l’estimation, ou regarde-t-on encore du bruit ?
Une certaine faiblesse est normale. Les systèmes distribués sont compliqués : les réseaux se figent, les paquets arrivent en retard.
Mon doute porte sur la stabilité de DUSK Network lorsque le modèle de délai cesse d’être favorable.
Un faible taux de forks compte. Savoir à quel point ce taux est incertain compte encore plus.
#dusk $DUSK
Trois forks sur 1 000 essais ressemble à 300 forks sur 100 000 essais. Même taux observé. Des preuves très différentes.
C’est pourquoi je ne m’arrêterais pas à un seul résultat de simulation.
Pour DUSK Network, l’étape 1 doit générer 100 000 profils aléatoires de délais de validateurs. L’étape 2 doit rejouer des conditions de propositions conflictuelles sur plusieurs distributions de latence, pas sur un seul modèle de réseau pratique. Ensuite, l’étape 3 convertit ces comptages de forks en probabilité, écart-type (erreur standard) et intervalles de confiance à 95 %.
Le problème caché n’est pas l’activité versus l’inactivité. Il s’agit de la résilience du protocole versus l’illusion statistique.
Les forks rares restent-ils rares quand les délais des validateurs deviennent biaisés ? Une seule distribution de latence domine-t-elle les échecs ? L’intervalle de confiance se resserre-t-il suffisamment pour faire confiance à l’estimation, ou regarde-t-on encore du bruit ?
Une certaine faiblesse est normale. Les systèmes distribués sont compliqués : les réseaux se figent, les paquets arrivent en retard.
Mon doute porte sur la stabilité de DUSK Network lorsque le modèle de délai cesse d’être favorable.
Un faible taux de forks compte. Savoir à quel point ce taux est incertain compte encore plus.
#dusk $DUSK
