ज़रा सोचिए कि आपके वॉलेट में फ़ंड हैं, अलग-अलग DeFi प्रोटोकॉल्स में पोज़ीशन्स हैं और कई सालों का ट्रांज़ैक्शन इतिहास है। अब कल्पना कीजिए कि आपको बताया जाए कि आपके खाता की सुरक्षा करने वाली क्रिप्टोग्राफी को बदलने की ज़रूरत है। क्या आप सच में सिर्फ़ सुरक्षित बने रहने के लिए एक और वॉलेट बनाना चाहेंगे, सब कुछ ट्रांसफ़र करें और अपनी सारी applications को दोबारा कनेक्ट करें? मैंने @Starknet के cryptographic agility रिसर्च को देखा है और मुझे लगता है कि यह ऐसा मसला है जिस पर और चर्चा होनी चाहिए। --> बिना फिर से शुरू किए सुरक्षा बदलना Starknet नेटिव account abstraction का इस्तेमाल करता है, यानी अकाउंट programmable smart contracts होते हैं। एक तय सिग्नेचर वेरिफ़िकेशन मेथड पर निर्भर रहने के बजाय, डेवलपर्स अकाउंट्स के लिए ट्रांज़ैक्शन authorize करने के अलग-अलग तरीके शामिल कर सकते हैं। इसका मतलब है कि compatible अकाउंट्स बिना नेटवर्क-स्तर के अपग्रेड के नई क्रिप्टोग्राफी अपना सकते हैं। यूज़र्स के लिए, इसका मतलब eventually यह हो सकता है कि वे अपना खाता सुरक्षा अपग्रेड कर सकें, जबकि वही address और फ़ंड्स बरक़रार रहें। मुझे यह इस उम्मीद से कहीं ज़्यादा व्यावहारिक लगता है कि सभी लोग एक ही समय पर migrate करें। --> देखने के लिए पहले से ही कुछ ठोस मौजूद है 25 अक्टूबर को, एक डेवलपर ने Starknet Sepolia पर टेस्ट की गई एक experimental migration साझा की। इस डेमोंस्ट्रेशन में 11 वॉलेट कॉन्ट्रैक्ट क्लासेज़ को कवर किया गया, जिनमें Argent, Braavos और OpenZeppelin implementations शामिल थीं। मौजूदा टेस्ट अकाउंट्स को उनकी addresses और फ़ंड्स को बनाए रखते हुए hybrid ECDSA और Falcon-512 signatures का इस्तेमाल करने के लिए अपग्रेड किया गया। माइग्रेशन के बाद, ट्रांज़ैक्शन्स के लिए दोनों signatures ज़रूरी थे, और पुराना केवल ECDSA वाला authorization path अस्वीकार कर दिया गया। यह एक महत्वपूर्ण विवरण है। किसी सुरक्षा मेथड को बदलना काफ़ी नहीं है अगर पुरानी, संभावित रूप से कमजोर मेथड का इस्तेमाल अभी भी किया जा सकता हो। यह implementation ऑडिट नहीं हुई है और सिर्फ़ testnet पर है, इसलिए यह अभी सबके लिए तैयार वॉलेट अपग्रेड नहीं है। फिर भी, मुझे अच्छा लगता है कि डेवलपर्स असली migration प्रक्रिया पर काम कर रहे हैं। --> @Starknet की आधारभूत सुरक्षा के बारे में क्या? STARK proofs और account signatures अलग-अलग उद्देश्यों की पूर्ति करते हैं। Hash-आधारित STARK proofs यह verify करते हैं कि computation सही तरह से किया गया, जबकि account signatures यह निर्धारित करते हैं कि ट्रांज़ैक्शन्स को authorize कौन कर सकता है। क्योंकि ये components अलग हैं, account signature verification बदलने के लिए पूरे proving system को बदलने की ज़रूरत नहीं पड़ती। StarkWare Quantum Hub भी cryptographic agility के आठ पहलुओं का मूल्यांकन करता है। 15 अक्टूबर 2026 के अपने assessment में, Starknet के पास checklist के निर्धारित दायरे के भीतर सभी आठ क्षमताओं का समर्थन करने वाले सार्वजनिक प्रमाण मौजूद थे। इसका मतलब यह नहीं है कि नेटवर्क पूरी तरह से quantum-resistant है। मौजूदा अकाउंट्स को अभी भी migration की ज़रूरत है और Starknet महत्वपूर्ण components के लिए ईथेरियम पर निर्भर है, जिनमें इसका bridge और data availability शामिल हैं। इन dependencies की अपनी सुरक्षा आवश्यकताएँ और अपग्रेड टाइमलाइन हैं। --> मेरे विचार मैं नहीं मानता कि quantum खतरों की तैयारी का मतलब यह होना चाहिए कि हम तब तक इंतज़ार करें जब तक कोई vulnerability आपातकाल न बन जाए। किसी को ठीक-ठीक नहीं पता कि quantum computing या AI-assisted गणित में प्रगति क्या उजागर कर सकती है। लेकिन हम अभी से ऐसी सुरक्षा अपग्रेड्स पर काम कर सकते हैं जो उन लोगों के लिए कम जटिल हों जो वास्तव में इन नेटवर्क्स का उपयोग करते हैं। मैं चाहूँगा कि वॉलेट डेवलपर्स इन migrations को आसान बनाएं, ख़ासकर key recovery, compatibility और यूज़र्स को अनजाने में कमज़ोर सुरक्षा पर वापस जाने से रोकने के मामले में। टेक्नोलॉजी होना एक बात है। उसे सामान्य यूज़र्स के लिए सुरक्षित और व्यावहारिक बनाना दूसरी बात है। @Starknet के काम के इसी हिस्से पर मैं नज़र रखूँगा। Research and methodology: https://t.co/bUHhv9TxJF Quantum Hub: https://t.co/veMp2WwDeT #Starknet #PostQuantum