Je ne lis plus la pause de la passerelle de Dusk comme une simple histoire de temps d’arrêt quand j’ai vu un échec de transfert de 8,91 millions de DUSK 15m55s après l’arrêt, tandis que DuskDS continuait de produire des blocs.
La métrique simple, c’est zéro indisponibilité du protocole. Utile, mais incomplet. Quatre transactions de vol ont retiré 10,91 millions de DUSK, mais seulement 1,919 million, soit 17,6%, a réussi à franchir jusqu’à la BSC. Le coupe-circuit du pont a limité la sortie, pas la compromission initiale du portefeuille.
Cette distinction compte. DuskDS pouvait encore régler les transactions natives pendant que les routes de liquidité externes étaient fermées. La disponibilité de la couche de base et la disponibilité de l’écosystème ne sont pas la même chose. Si les portefeuilles, les RPC, les explorateurs ou encore tous les principaux ponts sont indisponibles, DUSK est-il opérationnel pour les utilisateurs ou seulement « vivant » pour les validateurs ?
J’aimerais que Dusk publie cinq horloges séparées : chaînée, RPC, explorateur, portefeuille et disponibilité du pont, plus les blocs produits, la finalité médiane, le débit, les nouveaux comptes et l’activité native versus dépendante du pont pendant la pause. Sans ces séries, « non impacté » décrit le consensus, pas la demande.
L’absence de fonds utilisateurs et l’absence d’échec du protocole ont un sens. Mais le test le plus difficile est le comportement : l’activité native a-t-elle tenu lorsque les entrées se sont arrêtées, et quel coût d’opportunité s’est accumulé chaque jour d’indisponibilité ?
L’incident a montré que la chaîne pouvait survivre à la passerelle. Elle n’a pas encore montré que l’écosystème pouvait l’ignorer.
#dusk $DUSK @Dusk
La métrique simple, c’est zéro indisponibilité du protocole. Utile, mais incomplet. Quatre transactions de vol ont retiré 10,91 millions de DUSK, mais seulement 1,919 million, soit 17,6%, a réussi à franchir jusqu’à la BSC. Le coupe-circuit du pont a limité la sortie, pas la compromission initiale du portefeuille.
Cette distinction compte. DuskDS pouvait encore régler les transactions natives pendant que les routes de liquidité externes étaient fermées. La disponibilité de la couche de base et la disponibilité de l’écosystème ne sont pas la même chose. Si les portefeuilles, les RPC, les explorateurs ou encore tous les principaux ponts sont indisponibles, DUSK est-il opérationnel pour les utilisateurs ou seulement « vivant » pour les validateurs ?
J’aimerais que Dusk publie cinq horloges séparées : chaînée, RPC, explorateur, portefeuille et disponibilité du pont, plus les blocs produits, la finalité médiane, le débit, les nouveaux comptes et l’activité native versus dépendante du pont pendant la pause. Sans ces séries, « non impacté » décrit le consensus, pas la demande.
L’absence de fonds utilisateurs et l’absence d’échec du protocole ont un sens. Mais le test le plus difficile est le comportement : l’activité native a-t-elle tenu lorsque les entrées se sont arrêtées, et quel coût d’opportunité s’est accumulé chaque jour d’indisponibilité ?
L’incident a montré que la chaîne pouvait survivre à la passerelle. Elle n’a pas encore montré que l’écosystème pouvait l’ignorer.
#dusk $DUSK @Dusk