Le fait qu’init ait été appelé lors du déploiement ne signifie pas qu’il perd ensuite ses droits. La référence DuskVM indique clairement qu’après le déploiement, init reste un point d’entrée exporté. Ce détail déplace l’initialisation à usage unique de la garantie de la plateforme vers le contrôle d’accès du contrat lui-même. Si le code ne conserve pas de verrou d’état, le moment du déploiement n’est qu’une étape vécue, pas un sceau permanent.
Je répartis la responsabilité en deux colonnes. La plateforme est responsable de créer l’état initial et d’appeler pub fn init selon les paramètres lors du déploiement.@Dusk Le contrat lui-même est responsable d’enregistrer s’il a déjà été initialisé, de refuser les exécutions répétées lors des appels ultérieurs, et de vérifier aussi si le caller dispose des permissions. La première colonne garantit que la fonction est appelée, la seconde garantit qui peut la rappeler et combien de fois ; les deux colonnes ne peuvent pas se signer mutuellement.
Le risque ne réside pas dans le nom init, mais dans ce qu’il peut écrire. Adresse d’administrateur, mappage d’actifs, paramètres de frais ou adresse d’un contrat externe : dès lors qu’une seconde écriture est autorisée, les conditions de confiance établies lors du premier déploiement seront réinitialisées. On ne peut pas déduire une vulnérabilité du seul nom de la fonction ; les faits parlent : ce n’est que lorsque le code concret manque d’un bit d’état ou d’une vérification de l’appelant que l’initialisation répétée devient une surface d’attaque réelle.
$DUSK Si j’examine la configuration initiale d’un contrat, je chercherai trois preuves. Y a-t-il dans l’état persistant un indicateur initialized, le second appel échoue-t-il explicitement, et le caller est-il vérifié avant de modifier les champs clés ? Une transaction de déploiement ne peut répondre qu’à la question de savoir si l’exécution a eu lieu à ce moment-là ; elle ne peut pas dire qui pourra l’exécuter plus tard. Si l’audit ne capture que le premier reçu réussi, la question des permissions restera encore à moitié vide.
Cette comparaison en deux colonnes donne aussi aux utilisateurs ordinaires un critère utile. Si l’équipe du projet affirme que les paramètres ont été verrouillés lors du déploiement, on peut encore demander si ce verrouillage a été effectué par la machine virtuelle ou par le code du contrat. Le premier cas n’est pas conforme à la documentation ; dans le second, on devrait pouvoir trouver des preuves dans le code source et dans les tests de réappel. init est un point d’entrée du déploiement, mais aussi un point d’entrée public après le déploiement. La véritable unicité ne repose pas sur l’ordre temporel, mais sur le refus fondé sur l’état et l’autorisation de l’appelant.#dusk
Je répartis la responsabilité en deux colonnes. La plateforme est responsable de créer l’état initial et d’appeler pub fn init selon les paramètres lors du déploiement.@Dusk Le contrat lui-même est responsable d’enregistrer s’il a déjà été initialisé, de refuser les exécutions répétées lors des appels ultérieurs, et de vérifier aussi si le caller dispose des permissions. La première colonne garantit que la fonction est appelée, la seconde garantit qui peut la rappeler et combien de fois ; les deux colonnes ne peuvent pas se signer mutuellement.
Le risque ne réside pas dans le nom init, mais dans ce qu’il peut écrire. Adresse d’administrateur, mappage d’actifs, paramètres de frais ou adresse d’un contrat externe : dès lors qu’une seconde écriture est autorisée, les conditions de confiance établies lors du premier déploiement seront réinitialisées. On ne peut pas déduire une vulnérabilité du seul nom de la fonction ; les faits parlent : ce n’est que lorsque le code concret manque d’un bit d’état ou d’une vérification de l’appelant que l’initialisation répétée devient une surface d’attaque réelle.
$DUSK Si j’examine la configuration initiale d’un contrat, je chercherai trois preuves. Y a-t-il dans l’état persistant un indicateur initialized, le second appel échoue-t-il explicitement, et le caller est-il vérifié avant de modifier les champs clés ? Une transaction de déploiement ne peut répondre qu’à la question de savoir si l’exécution a eu lieu à ce moment-là ; elle ne peut pas dire qui pourra l’exécuter plus tard. Si l’audit ne capture que le premier reçu réussi, la question des permissions restera encore à moitié vide.
Cette comparaison en deux colonnes donne aussi aux utilisateurs ordinaires un critère utile. Si l’équipe du projet affirme que les paramètres ont été verrouillés lors du déploiement, on peut encore demander si ce verrouillage a été effectué par la machine virtuelle ou par le code du contrat. Le premier cas n’est pas conforme à la documentation ; dans le second, on devrait pouvoir trouver des preuves dans le code source et dans les tests de réappel. init est un point d’entrée du déploiement, mais aussi un point d’entrée public après le déploiement. La véritable unicité ne repose pas sur l’ordre temporel, mais sur le refus fondé sur l’état et l’autorisation de l’appelant.#dusk