Publier
--
Eman098
·
--
#dusk $DUSK @Dusk
Ce qui a attiré mon attention en parcourant la documentation de Dusk : il n’existe que deux contrats. À la genèse, il y a le contrat de mise (stake) et le contrat de transfert. Tout le reste, y compris DuskVM et DuskEVM, repose au-dessus d’eux.
C’est une concentration assez étrange pour une chaîne conçue pour régler des actifs réglementés. J’ai donc voulu vérifier ce que font exactement ces deux contrats et s’ils peuvent être modifiés plus tard.
Le contrat de mise (stake) suit les prestataires (provisioners) : combien ils ont mis en jeu, quand les récompenses arrivent à maturité, et comment s’applique la pénalité (slashing). Le contrat de transfert gère à la fois les soldes publics (Moonlight) et les soldes protégés (Phoenix) — et c’est le seul endroit où, concrètement, les mouvements de fonds entre contrats se produisent. D’après la documentation actuelle, tout environnement d’exécution y achemine ses traitements pour le règlement et la disponibilité des données.
Pourquoi c’est important : si vous construisez sur DuskEVM ou si vous émettez des actifs via Dusk Trade, vous ne faites pas qu’avoir confiance dans la logique de votre propre contrat. Vous faites confiance au fait que ces deux contrats de genèse se comportent correctement indéfiniment, puisqu’ils constituent le substrat de règlement sur lequel tout le reste s’appuie.
Voici ce que je n’ai pas réussi à éclaircir. La documentation décrit ces contrats comme étant refactorisés au fil du temps : le contrat de mise a été reconstruit pour corriger un problème de stockage, puis des mises à jour d’ingénierie ont modifié sa structure d’événements. Donc ils ne sont manifestement pas figés au sens « immuable dès la genèse ».
Ce qui m’échappe, c’est le cheminement réel de mise à niveau : est-ce discrétionnaire (l’équipe protocole déploie une mise à jour réseau) ou existe-t-il une étape formelle de gouvernance on-chain où les provisioners votent avant que la logique des contrats de genèse ne change ? La documentation que j’ai trouvée décrit ce que font les contrats, mais pas comment leurs modifications sont autorisées.
Pour une chaîne qui se positionne pour le règlement institutionnel, cette distinction entre « mise à niveau autorisée par l’équipe » et « mise à niveau ratifiée par les provisioners » devrait, selon moi, être documentée explicitement quelque part.
Quelqu’un a-t-il vu où <@Dusk > précise le processus d’autorisation réel pour les changements de contrats de genèse ?
$DUSK #dusk
Ce qui a attiré mon attention en parcourant la documentation de Dusk : il n’existe que deux contrats. À la genèse, il y a le contrat de mise (stake) et le contrat de transfert. Tout le reste, y compris DuskVM et DuskEVM, repose au-dessus d’eux.
C’est une concentration assez étrange pour une chaîne conçue pour régler des actifs réglementés. J’ai donc voulu vérifier ce que font exactement ces deux contrats et s’ils peuvent être modifiés plus tard.
Le contrat de mise (stake) suit les prestataires (provisioners) : combien ils ont mis en jeu, quand les récompenses arrivent à maturité, et comment s’applique la pénalité (slashing). Le contrat de transfert gère à la fois les soldes publics (Moonlight) et les soldes protégés (Phoenix) — et c’est le seul endroit où, concrètement, les mouvements de fonds entre contrats se produisent. D’après la documentation actuelle, tout environnement d’exécution y achemine ses traitements pour le règlement et la disponibilité des données.
Pourquoi c’est important : si vous construisez sur DuskEVM ou si vous émettez des actifs via Dusk Trade, vous ne faites pas qu’avoir confiance dans la logique de votre propre contrat. Vous faites confiance au fait que ces deux contrats de genèse se comportent correctement indéfiniment, puisqu’ils constituent le substrat de règlement sur lequel tout le reste s’appuie.
Voici ce que je n’ai pas réussi à éclaircir. La documentation décrit ces contrats comme étant refactorisés au fil du temps : le contrat de mise a été reconstruit pour corriger un problème de stockage, puis des mises à jour d’ingénierie ont modifié sa structure d’événements. Donc ils ne sont manifestement pas figés au sens « immuable dès la genèse ».
Ce qui m’échappe, c’est le cheminement réel de mise à niveau : est-ce discrétionnaire (l’équipe protocole déploie une mise à jour réseau) ou existe-t-il une étape formelle de gouvernance on-chain où les provisioners votent avant que la logique des contrats de genèse ne change ? La documentation que j’ai trouvée décrit ce que font les contrats, mais pas comment leurs modifications sont autorisées.
Pour une chaîne qui se positionne pour le règlement institutionnel, cette distinction entre « mise à niveau autorisée par l’équipe » et « mise à niveau ratifiée par les provisioners » devrait, selon moi, être documentée explicitement quelque part.
Quelqu’un a-t-il vu où <@Dusk > précise le processus d’autorisation réel pour les changements de contrats de genèse ?
$DUSK #dusk
Avertissement : ce contenu inclut des opinions de tiers. Il ne constitue pas un conseil. Binance Ai peut être utilisée, sans garantie de résultat. Consultez les CG.