De nombreuses conceptions précoces de blockchain utilisaient le hachage Pedersen car il est efficace au sein des groupes de courbes elliptiques et s'associe naturellement aux mêmes courbes utilisées pour les signatures. La sécurité de Pedersen, cependant, hérite de l'hypothèse du logarithme discret. Le remplacement de ce dernier par une fonction de hachage dont la sécurité repose uniquement sur la résistance aux collisions élimine cette dépendance. @Starknet a effectué ce remplacement pour le hachage du programme du système d'exploitation et le hachage de configuration qui apparaissent dans le contrat principal. Ce changement était limité en portée, mais il a clos un élément concret du calendrier publié et a démontré que de tels remplacements peuvent être effectués sans perturber les comptes existants. D'autres remplacements restent prévus dans le calendrier : les engagements du state trie et la dérivation des adresses de contrat. Étant donné que ces valeurs sont déjà engagées sur la blockchain, tout changement doit être accompagné d'une stratégie de migration pour les données historiques. Une approche en discussion consiste à développer des outils permettant aux contrats existants de re-dériver les clés de stockage sous le nouveau hachage sans déplacement manuel des données. Le coût ingénierie est non négligeable, mais il est localisé et peut avancer indépendamment du calendrier de la couche de règlement. Ces étapes progressives illustrent un modèle pratique. Plutôt que d'attendre un seul fork dur quantiquement sécurisé, un réseau peut éliminer progressivement les hypothèses basées sur les courbes elliptiques, surface par surface, en déployant chaque changement dès que l'implémentation et le chemin de migration sont prêts. Un registre public de migration qui suit l'état de chaque surface rend la distance restante observable plutôt que rhétorique.