#dusk $DUSK @Dusk
Pour juger si un projet crypto est fiable, je ne me fie pas à la beauté de son rapport hebdomadaire : je regarde plutôt comment il réagit quand des gens soulèvent publiquement des points techniques sensibles, et surtout comment il y répond. Il y a quelques jours, sur le canal technique de Discord de Dusk, un utilisateur a attaqué le contrat XSC sur l’efficacité d’exécution dans un contexte de charge spécifique. En général, chez d’autres projets, on se contente souvent d’envoyer à la place une phrase du type « voir la documentation ». Chez Dusk, les administrateurs ont directement transmis le problème au dev principal. Le lendemain, la personne a publié une réponse longue, avec des benchmarks : elle expliquait clairement quelles limites faisaient ralentir, et dans quels scénarios les coûts liés à ZK restaient acceptables.
Ce genre de communication où la couche “core” ne se contente pas de construire des murs, mais s’implique réellement, est atypique dans le milieu des cryptos. La plupart des projets, au début, reposent sur le fondateur pour “faire face”, puis au milieu, on te confie le sujet à des bénévoles dont tu n’arrives même pas à retenir le nom, et à la fin, même ces bénévoles finissent par s’épuiser : il ne reste plus que des comptes-rendus pour se faire plaisir. Dusk donne aujourd’hui l’impression que les vrais problèmes sont pris en charge, et qu’une fois pris en charge, ils ne sont pas traités à la légère : on répond avec des données. Pour une équipe qui travaille sur la conformité, la confidentialité + un L1, cette “couleur de fond” vaut plus que n’importe quel slogan marketing.
Mais je ne vais pas pour autant baisser ma vigilance. La convivialité a une fenêtre. Quand le projet est petit, qu’il y a peu de questions et que les effectifs côté cœur sont suffisants, ça tient. Quand le réseau principal DuskEVM se déploiera et que le flux d’institutions RWA arrivera, le volume de questions changera forcément. Les développeurs ne pourront pas toujours intervenir personnellement. À ce moment-là, si des bénévoles “orientés technique” n’ont pas été formés, et si la documentation ne suit pas les itérations, la bonne réputation d’aujourd’hui pourrait se retourner contre le projet et devenir une preuve que “c’était juste du décor” au début. J’ai vu trop de projets où l’on répondait aux benchmarks pendant les trois premiers mois, puis où tout le monde répond “vu” les trois mois suivants. Le tournant arrive souvent au moment où l’ampleur des utilisateurs franchit un certain seuil.
Donc, ce que Dusk devrait faire maintenant, ce n’est pas de continuer à demander au dev principal de compenser par la vitesse d’exécution. Il faut plutôt capitaliser ces réponses en une FAQ consultable, ouvrir les scripts de benchmark, et formaliser le processus de “qui transfère à qui et qui répond”. Il faut que la convivialité devienne un système, pas un mode de production à combustion de quelques personnes. Lent à s’installer, sans crier sur les lancements, et axé sur la technique plutôt que sur le prix : cette ambiance est une barrière de protection pour les gens qui misent sur le long terme. Mais une barrière de protection, ça nécessite aussi qu’on fasse le nettoyage au quotidien ; sinon, dès que les utilisateurs augmentent, la “boue” s’accumule et finit par étouffer.
Pour juger si un projet crypto est fiable, je ne me fie pas à la beauté de son rapport hebdomadaire : je regarde plutôt comment il réagit quand des gens soulèvent publiquement des points techniques sensibles, et surtout comment il y répond. Il y a quelques jours, sur le canal technique de Discord de Dusk, un utilisateur a attaqué le contrat XSC sur l’efficacité d’exécution dans un contexte de charge spécifique. En général, chez d’autres projets, on se contente souvent d’envoyer à la place une phrase du type « voir la documentation ». Chez Dusk, les administrateurs ont directement transmis le problème au dev principal. Le lendemain, la personne a publié une réponse longue, avec des benchmarks : elle expliquait clairement quelles limites faisaient ralentir, et dans quels scénarios les coûts liés à ZK restaient acceptables.
Ce genre de communication où la couche “core” ne se contente pas de construire des murs, mais s’implique réellement, est atypique dans le milieu des cryptos. La plupart des projets, au début, reposent sur le fondateur pour “faire face”, puis au milieu, on te confie le sujet à des bénévoles dont tu n’arrives même pas à retenir le nom, et à la fin, même ces bénévoles finissent par s’épuiser : il ne reste plus que des comptes-rendus pour se faire plaisir. Dusk donne aujourd’hui l’impression que les vrais problèmes sont pris en charge, et qu’une fois pris en charge, ils ne sont pas traités à la légère : on répond avec des données. Pour une équipe qui travaille sur la conformité, la confidentialité + un L1, cette “couleur de fond” vaut plus que n’importe quel slogan marketing.
Mais je ne vais pas pour autant baisser ma vigilance. La convivialité a une fenêtre. Quand le projet est petit, qu’il y a peu de questions et que les effectifs côté cœur sont suffisants, ça tient. Quand le réseau principal DuskEVM se déploiera et que le flux d’institutions RWA arrivera, le volume de questions changera forcément. Les développeurs ne pourront pas toujours intervenir personnellement. À ce moment-là, si des bénévoles “orientés technique” n’ont pas été formés, et si la documentation ne suit pas les itérations, la bonne réputation d’aujourd’hui pourrait se retourner contre le projet et devenir une preuve que “c’était juste du décor” au début. J’ai vu trop de projets où l’on répondait aux benchmarks pendant les trois premiers mois, puis où tout le monde répond “vu” les trois mois suivants. Le tournant arrive souvent au moment où l’ampleur des utilisateurs franchit un certain seuil.
Donc, ce que Dusk devrait faire maintenant, ce n’est pas de continuer à demander au dev principal de compenser par la vitesse d’exécution. Il faut plutôt capitaliser ces réponses en une FAQ consultable, ouvrir les scripts de benchmark, et formaliser le processus de “qui transfère à qui et qui répond”. Il faut que la convivialité devienne un système, pas un mode de production à combustion de quelques personnes. Lent à s’installer, sans crier sur les lancements, et axé sur la technique plutôt que sur le prix : cette ambiance est une barrière de protection pour les gens qui misent sur le long terme. Mais une barrière de protection, ça nécessite aussi qu’on fasse le nettoyage au quotidien ; sinon, dès que les utilisateurs augmentent, la “boue” s’accumule et finit par étouffer.