POURQUOI DUSK NE FAIT PAS EN SORTE qu’UN SEUL NŒUD FASSE TOUT
Il y a deux semaines, j’essayais d’économiser sur un VPS. J’ai mis mon application principale, les sauvegardes de la base de données et une tâche lourde de traitement d’images sur le même petit serveur. Ça semblait efficace. Ce ne l’était pas. La tâche d’images se lançait, et soudain mon application principale manquait de requêtes.
Ce stupide problème de petit VPS me revient quand je lis la configuration des nœuds de Dusk. Dusk sépare le travail entre les rôles de Provisioner, d’Archive et de Prover. Ce ne sont pas trois noms élégants pour une seule machine qui fait tout.
Un Provisioner se concentre sur le consensus et a besoin d’au moins 1 000 DUSK mis en jeu. Un nœud Archive conserve l’historique finalisé pour des éléments comme « moonlightHistory » et « finalizedEvents ». Un Prover gère la partie la plus lourde du travail de preuve à Zéro-Connaissance.
Ensuite, j’arrive au Prover et le problème matériel change à nouveau. Dusk indique que la génération de preuves est mono-thread, donc de solides performances sur un seul cœur sont importantes. L’infrastructure Archive démarre avec d’autres exigences : 4 cœurs, 8 Go de RAM, 500 Go de stockage et un réseau de 100 Mbps.
Et c’est la partie qui me semble familière. Dusk recommande de garder l’infrastructure API de production séparée des tâches de Provisioner, car le trafic de requêtes et la maintenance peuvent entrer en concurrence avec le travail de consensus. J’ai appris la même chose, de la manière la plus pénible, sur ce VPS.
Désormais, je regarde ces trois rôles un peu différemment. Si le consensus, les requêtes historiques et la génération de preuves ZK se battent tous pour les mêmes ressources, peut-être qu’une seule machine qui fait tout n’est pas en réalité l’option la plus simple.
@Dusk #dusk $DUSK
Il y a deux semaines, j’essayais d’économiser sur un VPS. J’ai mis mon application principale, les sauvegardes de la base de données et une tâche lourde de traitement d’images sur le même petit serveur. Ça semblait efficace. Ce ne l’était pas. La tâche d’images se lançait, et soudain mon application principale manquait de requêtes.
Ce stupide problème de petit VPS me revient quand je lis la configuration des nœuds de Dusk. Dusk sépare le travail entre les rôles de Provisioner, d’Archive et de Prover. Ce ne sont pas trois noms élégants pour une seule machine qui fait tout.
Un Provisioner se concentre sur le consensus et a besoin d’au moins 1 000 DUSK mis en jeu. Un nœud Archive conserve l’historique finalisé pour des éléments comme « moonlightHistory » et « finalizedEvents ». Un Prover gère la partie la plus lourde du travail de preuve à Zéro-Connaissance.
Ensuite, j’arrive au Prover et le problème matériel change à nouveau. Dusk indique que la génération de preuves est mono-thread, donc de solides performances sur un seul cœur sont importantes. L’infrastructure Archive démarre avec d’autres exigences : 4 cœurs, 8 Go de RAM, 500 Go de stockage et un réseau de 100 Mbps.
Et c’est la partie qui me semble familière. Dusk recommande de garder l’infrastructure API de production séparée des tâches de Provisioner, car le trafic de requêtes et la maintenance peuvent entrer en concurrence avec le travail de consensus. J’ai appris la même chose, de la manière la plus pénible, sur ce VPS.
Désormais, je regarde ces trois rôles un peu différemment. Si le consensus, les requêtes historiques et la génération de preuves ZK se battent tous pour les mêmes ressources, peut-être qu’une seule machine qui fait tout n’est pas en réalité l’option la plus simple.
@Dusk #dusk $DUSK