Dans les systèmes sans abstraction de compte native, changer le schéma de signature utilisé par les utilisateurs ordinaires signifie généralement l’une des deux choses : un hard fork au niveau du protocole qui met à jour le format des transactions pour tous, ou une migration massive au cours de laquelle les utilisateurs doivent transférer leurs fonds vers de nouvelles adresses qui implémentent déjà le nouveau schéma. Les deux options introduisent des coûts de coordination, un risque d’erreur utilisateur et une fragmentation temporaire de la liquidité. L’abstraction de compte native inverse ce modèle. Étant donné que le compte est lui-même un contrat intelligent, sa fonction de validation peut être remplacée via un chemin de mise à jour authentifié défini par la logique propre au compte. L’adresse et le stockage restent inchangés ; seule la code qui détermine si une signature est valide est mise à jour. @Starknet implémente ce modèle par défaut. Des démonstrations publiques ont montré la vérification Falcon-512 en cours d’exécution à l’intérieur d’un contrat de compte, et un autre proof-of-concept a utilisé une clé ML-DSA stockée dans l’élément sécurisé d’un téléphone. Ces implémentations ne sont pas encore prêtes pour une utilisation en production par les utilisateurs ordinaires, car elles restent non auditées sous certains aspects cruciaux et manquent de support large au niveau des wallets, mais elles illustrent que le mécanisme existe. Le coût en gaz de la vérification est supérieur à celui de l’ECDSA classique, mais il a été démontré qu’il s’inscrit dans les limites actuelles par transaction dans des variantes optimisées. Le travail restant est donc principalement externe au protocole central : les interfaces wallet doivent prendre en charge les nouveaux formats de clés, les custodians doivent mettre à jour leur infrastructure de signature, et les utilisateurs doivent se voir offrir des chemins de mise à jour clairs qui n’emprisonnent pas les comptes si une version intermédiaire n’est pas prise en charge. L’agilité cryptographique au niveau du compte réduit la portée du changement coordonné, mais ne supprime pas la nécessité d’une ingénierie soigneuse de l’écosystème environnant.