#dusk $DUSK
Le nom « Rusk » revenait constamment dans la documentation de Dusk, sans explication claire de ce qu’il s’agit réellement. Il s’agit de l’implémentation de nœud de référence — et comprendre ce que « nœud » recouvre dans ce contexte mérite d’être précis.
Partie surprenante : Rusk ne se contente pas de relayer des blocs. Il exécute l’intégralité du protocole de consensus, y compris la génération des blocs et le vote du comité. Il maintient l’état complet de la chaîne. Il exécute les contrats DuskVM. Il expose des APIs et des événements pour que les applications puissent les consommer.
La mise à niveau Boreas, qui correspond à Rusk v1.7.0, était en testnet à la mi-2026 — la prochaine mise à jour au niveau protocole après Aegis (mars 2026). Chaque mise à niveau est déployée sur testnet avant la mainnet, afin de laisser aux opérateurs le temps de valider.
Sur Ethereum, le logiciel du nœud est distinct du client d’exécution. Rusk réunit les deux dans une seule implémentation de référence : c’est à la fois le participant au consensus ET l’exécuteur de contrats intelligents. Le même processus gère les deux couches.
À comparer à une architecture en couches comme Ethereum+Geth : le protocole et le client d’exécution sont maintenus séparément et peuvent être remplacés. Rusk, lui, est une implémentation de référence unique. Cela simplifie la coordination des mises à niveau, mais crée une chaîne de dépendances unique pour les opérateurs.
Je trouve d’ailleurs le choix d’une seule implémentation de référence intéressant pour une chaîne visant des marchés réglementés — les infrastructures régulées privilégient généralement la diversité des clients afin d’éviter les bugs liés à une implémentation unique.
Dusk prévoit-il des implémentations de nœuds alternatives, ou Rusk est-il le seul client de production par conception ? @Dusk
$DUSK #dusk
Le nom « Rusk » revenait constamment dans la documentation de Dusk, sans explication claire de ce qu’il s’agit réellement. Il s’agit de l’implémentation de nœud de référence — et comprendre ce que « nœud » recouvre dans ce contexte mérite d’être précis.
Partie surprenante : Rusk ne se contente pas de relayer des blocs. Il exécute l’intégralité du protocole de consensus, y compris la génération des blocs et le vote du comité. Il maintient l’état complet de la chaîne. Il exécute les contrats DuskVM. Il expose des APIs et des événements pour que les applications puissent les consommer.
La mise à niveau Boreas, qui correspond à Rusk v1.7.0, était en testnet à la mi-2026 — la prochaine mise à jour au niveau protocole après Aegis (mars 2026). Chaque mise à niveau est déployée sur testnet avant la mainnet, afin de laisser aux opérateurs le temps de valider.
Sur Ethereum, le logiciel du nœud est distinct du client d’exécution. Rusk réunit les deux dans une seule implémentation de référence : c’est à la fois le participant au consensus ET l’exécuteur de contrats intelligents. Le même processus gère les deux couches.
À comparer à une architecture en couches comme Ethereum+Geth : le protocole et le client d’exécution sont maintenus séparément et peuvent être remplacés. Rusk, lui, est une implémentation de référence unique. Cela simplifie la coordination des mises à niveau, mais crée une chaîne de dépendances unique pour les opérateurs.
Je trouve d’ailleurs le choix d’une seule implémentation de référence intéressant pour une chaîne visant des marchés réglementés — les infrastructures régulées privilégient généralement la diversité des clients afin d’éviter les bugs liés à une implémentation unique.
Dusk prévoit-il des implémentations de nœuds alternatives, ou Rusk est-il le seul client de production par conception ? @Dusk
$DUSK #dusk
