Lors du démarrage du réseau Dusk, ce n’est pas seulement la machine virtuelle Piecrust qui entre en jeu : il faut aussi déployer un ensemble de contrats de genèse, qui assurent les opérations les plus fondamentales. Dans la section 6.2 du livre blanc, on les appelle « genesis contracts ». Il s’agit de contrats intelligents spéciaux déployés lors de l’initialisation du réseau, responsables de fonctions essentielles telles que la validation des transactions, le mécanisme de mise sous garantie (staking) et la répartition initiale des jetons. Le livre blanc met particulièrement l’accent sur deux d’entre eux.
Le premier est le contrat de transfert (transfer contract). Il gère tous les transferts de DUSK, $DUSK tout en traitant simultanément la déduction des frais de gaz. Si une transaction inclut un déploiement ou un appel de contrat intelligent, le transfer contract prend également en charge le traitement : il vérifie que la transaction respecte les règles de Moonlight ou Phoenix, puis déduit les frais de gaz correspondants du solde de l’expéditeur. Le livre blanc indique que c’est « le point d’entrée dans la blockchain Dusk », et que toutes les transactions doivent finalement passer par lui.
Le second est le contrat de mise sous garantie (stake contract). Il gère l’ensemble du cycle de vie du staking : il vérifie que le montant déposé par l’utilisateur atteint le seuil minimal requis, verrouille les jetons et enregistre l’utilisateur comme provisioner. Plus l’utilisateur mise de DUSK, plus la probabilité qu’il soit sélectionné par l’algorithme DS pour participer au consensus est élevée. Le contrat traite aussi les demandes de désengagement : une fois la période de verrouillage terminée, l’utilisateur peut récupérer ses jetons, tout en garantissant que l’émission des récompenses et la déduction des pénalités s’exécutent correctement. Le seuil de 1000 DUSK mentionné à l’« angle 1 », ainsi que les récompenses et pénalités évoquées à l’« angle 9 », prennent effet concrètement grâce à ce contrat. @Dusk
La section 6.3 ajoute encore deux autres « contrats ». L’un est le contrat de licence (license contract). Basé sur le protocole Citadel, il gère l’émission et la validation des licences au sein du réseau : il suit la propriété, la validité et les dates d’expiration de chaque licence, et traite les révocations ou les renouvellements. L’autre est le ensemble de contrats Zedger : il instancie un contrat intelligent distinct pour chaque type d’actif de titres, fournissant des fonctions telles que le mint (émission), le burn (destruction), la distribution de dividendes et le transfert forcé, et constitue la mise en œuvre concrète du protocole Zedger évoqué à l’« angle 7 ».
La répartition des rôles entre les quatre contrats est très claire : le transfer contract gère la liquidité, le stake contract gère la participation au consensus, le license contract gère les permissions, et les contrats Zedger gèrent les actifs. Mais cela implique aussi que les fonctions essentielles de Dusk dépendent fortement de la correction de ces quatre contrats : si l’un d’entre eux présente un bug, ce n’est pas seulement une application isolée qui est touchée, mais les opérations de base de l’ensemble du réseau. #dusk
Le premier est le contrat de transfert (transfer contract). Il gère tous les transferts de DUSK, $DUSK tout en traitant simultanément la déduction des frais de gaz. Si une transaction inclut un déploiement ou un appel de contrat intelligent, le transfer contract prend également en charge le traitement : il vérifie que la transaction respecte les règles de Moonlight ou Phoenix, puis déduit les frais de gaz correspondants du solde de l’expéditeur. Le livre blanc indique que c’est « le point d’entrée dans la blockchain Dusk », et que toutes les transactions doivent finalement passer par lui.
Le second est le contrat de mise sous garantie (stake contract). Il gère l’ensemble du cycle de vie du staking : il vérifie que le montant déposé par l’utilisateur atteint le seuil minimal requis, verrouille les jetons et enregistre l’utilisateur comme provisioner. Plus l’utilisateur mise de DUSK, plus la probabilité qu’il soit sélectionné par l’algorithme DS pour participer au consensus est élevée. Le contrat traite aussi les demandes de désengagement : une fois la période de verrouillage terminée, l’utilisateur peut récupérer ses jetons, tout en garantissant que l’émission des récompenses et la déduction des pénalités s’exécutent correctement. Le seuil de 1000 DUSK mentionné à l’« angle 1 », ainsi que les récompenses et pénalités évoquées à l’« angle 9 », prennent effet concrètement grâce à ce contrat. @Dusk
La section 6.3 ajoute encore deux autres « contrats ». L’un est le contrat de licence (license contract). Basé sur le protocole Citadel, il gère l’émission et la validation des licences au sein du réseau : il suit la propriété, la validité et les dates d’expiration de chaque licence, et traite les révocations ou les renouvellements. L’autre est le ensemble de contrats Zedger : il instancie un contrat intelligent distinct pour chaque type d’actif de titres, fournissant des fonctions telles que le mint (émission), le burn (destruction), la distribution de dividendes et le transfert forcé, et constitue la mise en œuvre concrète du protocole Zedger évoqué à l’« angle 7 ».
La répartition des rôles entre les quatre contrats est très claire : le transfer contract gère la liquidité, le stake contract gère la participation au consensus, le license contract gère les permissions, et les contrats Zedger gèrent les actifs. Mais cela implique aussi que les fonctions essentielles de Dusk dépendent fortement de la correction de ces quatre contrats : si l’un d’entre eux présente un bug, ce n’est pas seulement une application isolée qui est touchée, mais les opérations de base de l’ensemble du réseau. #dusk