
Une chose que j’ai commencé à apprécier concernant la sécurité de la blockchain, c’est que être sécurisé aujourd’hui ne signifie pas automatiquement être prêt pour demain. L’informatique quantique et les percées mathématiques assistées par l’IA pourraient éventuellement remettre en question certaines des hypothèses cryptographiques sur lesquelles nous comptons. Personne ne sait exactement quand ni comment cela pourrait se produire, mais préparer le changement est quelque chose que l’infrastructure devrait envisager bien avant qu’il ne devienne urgent. C’est là que @Starknet a retenu mon attention. Son architecture de sécurité présente une séparation intéressante des responsabilités. Les preuves STARK utilisent une cryptographie basée sur des fonctions de hachage pour vérifier que les calculs ont été effectués correctement. En parallèle, l’autorisation des transactions est gérée via des comptes programmables, car les comptes Starknet sont des contrats intelligents et non des règles de signature fixes au niveau du protocole. Cette distinction est plus importante qu’il n’y paraît. Si un nouveau schéma de signature devient nécessaire, un compte peut adopter une méthode de vérification différente sans exiger que tous les utilisateurs du réseau mettent à jour simultanément leurs logiciels. Autrement dit, la couche de preuve et la couche d’autorisation peuvent évoluer indépendamment. Mais la flexibilité au niveau du compte n’est qu’une partie de l’image. En tant que L2 d’Ethereum, Starknet dépend toujours des fondements cryptographiques d’Ethereum et de son calendrier de mise à jour et de migration dans les domaines liés à Ethereum. Même si Starknet peut adapter certaines parties de sa sécurité de compte, certains changements impliquent finalement des dépendances au-delà de son contrôle direct. C’est pourquoi son exploration d’un L1 indépendant mérite d’être suivie. Un contrôle plus grand sur sa propre infrastructure pourrait donner à Starknet plus de liberté pour coordonner les mises à jour de sécurité critiques et répondre aux nouvelles exigences cryptographiques sans dépendre entièrement du calendrier d’Ethereum. Je vois ici deux idées différentes mais connectées : → Les comptes programmables offrent une flexibilité aux utilisateurs et développeurs pour modifier les méthodes d’authentification. → Un L1 indépendant pourrait offrir une plus grande autonomie dans les décisions de sécurité au niveau du réseau. Aucune de ces deux approches ne signifie que Starknet est déjà entièrement résistant à l’ordinateur quantique. Les comptes existants, les dépendances liées à Ethereum et les travaux de migration restent importants. Certaines implémentations post-quantiques sont également expérimentales et ne doivent pas être confondues avec des solutions auditées et prêtes à la production. Ce que je trouve le plus intéressant, c’est la philosophie plus vaste qui sous-tend tout cela. Nous ne pouvons pas construire la sécurité en supposant que la cryptographie actuelle restera suffisante pour toujours. Nous avons besoin de systèmes capables d’évoluer sans avoir à tout reconstruire depuis le début. Pour moi, l’agilité cryptographique ne concerne pas seulement la préparation aux menaces quantiques. C’est aussi s’assurer qu’une blockchain a la capacité de réagir lorsque les règles de sécurité évolueront inévitablement. Plus de recherches : https://t.co/A5MiaKoy3t @Starknet

