#dusk $DUSK L’expérience des nœuds DUSK ressemble beaucoup à de la maintenance pour une blockchain en cours d’itération rapide, plutôt qu’à un nœud “léger” que l’on branche et qu’on peut ensuite laisser tranquille. La fréquence de mise à jour des nœuds Rusk n’est pas faible : à chaque mise à jour, le journal de changements contient aussi certaines configurations indispensables à terminer. Si l’on n’y fait pas attention, on risque de se faire distancer sur le testnet. Surtout, les mises à jour du réseau DUSK se déclenchent généralement par la hauteur de bloc, et ne se limitent pas à un point de temps précis. Cela signifie que les opérateurs de nœuds doivent surveiller eux-mêmes la progression de la synchronisation, et vérifier que le nœud a bien été passé à la nouvelle version avant d’atteindre la hauteur cible.
Sur le testnet de DUSK, j’ai rencontré une situation : après la mise à niveau, l’utilisation du CPU a soudainement grimpé, et les journaux étaient remplis de calculs intensifs liés à la vérification des preuves à connaissance nulle. À ce moment-là, si l’on se contente de lancer avec la configuration minimale, on peut facilement observer des retards à proximité des blocs où la vérification des preuves devient très dense. Le fait que ce problème se manifeste sur le testnet est plutôt une bonne chose : cela signifie au moins que le cœur de DUSK n’est pas figé. Mais cela rappelle aussi à ceux qui veulent participer à des nœuds sur le mainnet que les exigences envers la configuration des machines et la surveillance quotidienne d’un nœud DUSK sont plus élevées que ce qu’on imagine.
En soi, le hard fork, dans DUSK, ressemble davantage à un test de coordination forcée à l’échelle du réseau. Quand le nombre de nœuds n’est pas encore assez important, l’efficacité des mises à niveau pilotées par l’équipe centrale est plus élevée. En revanche, cela indique aussi que le degré de décentralisation reste encore à un stade précoce. Ce que peuvent faire les opérateurs de nœuds, c’est, lors de chaque mise à jour sur le testnet, exécuter un processus de mise à niveau complet et consigner les différences de configuration, l’augmentation de l’espace disque et les alertes de journaux. Sinon, au moment des mises à niveau critiques sur le mainnet, de petits détails peuvent facilement affecter la stabilité de l’ensemble du réseau.
Je préférerais que DUSK fournisse à l’avenir des outils plus fins de contrôle de santé des nœuds et des rappels de mise à niveau, plutôt que de laisser aux opérateurs le soin de fouiller dans les journaux des versions. Plus la couche de fondation du réseau est stable, plus DuskEVM et les applications de la couche supérieure auront une chance d’être traités sérieusement. #dusk @Dusk $DUSK
Sur le testnet de DUSK, j’ai rencontré une situation : après la mise à niveau, l’utilisation du CPU a soudainement grimpé, et les journaux étaient remplis de calculs intensifs liés à la vérification des preuves à connaissance nulle. À ce moment-là, si l’on se contente de lancer avec la configuration minimale, on peut facilement observer des retards à proximité des blocs où la vérification des preuves devient très dense. Le fait que ce problème se manifeste sur le testnet est plutôt une bonne chose : cela signifie au moins que le cœur de DUSK n’est pas figé. Mais cela rappelle aussi à ceux qui veulent participer à des nœuds sur le mainnet que les exigences envers la configuration des machines et la surveillance quotidienne d’un nœud DUSK sont plus élevées que ce qu’on imagine.
En soi, le hard fork, dans DUSK, ressemble davantage à un test de coordination forcée à l’échelle du réseau. Quand le nombre de nœuds n’est pas encore assez important, l’efficacité des mises à niveau pilotées par l’équipe centrale est plus élevée. En revanche, cela indique aussi que le degré de décentralisation reste encore à un stade précoce. Ce que peuvent faire les opérateurs de nœuds, c’est, lors de chaque mise à jour sur le testnet, exécuter un processus de mise à niveau complet et consigner les différences de configuration, l’augmentation de l’espace disque et les alertes de journaux. Sinon, au moment des mises à niveau critiques sur le mainnet, de petits détails peuvent facilement affecter la stabilité de l’ensemble du réseau.
Je préférerais que DUSK fournisse à l’avenir des outils plus fins de contrôle de santé des nœuds et des rappels de mise à niveau, plutôt que de laisser aux opérateurs le soin de fouiller dans les journaux des versions. Plus la couche de fondation du réseau est stable, plus DuskEVM et les applications de la couche supérieure auront une chance d’être traités sérieusement. #dusk @Dusk $DUSK
节点门槛比想象中高
0%
工具链还需更完善
50%
测试网体验很有参考价值
50%
2 Votes • Vote fermé