Seraphis और Jamtis: Monero का अगला प्रोटोकॉल लीप

जब Monero Research Lab ने 2025 के अंत में पहली ऑडिटेड Seraphis लाइब्रेरी ब्रांच को testing fork में चुपचाप merge किया, तब यह पुष्टि हो गई जिस पर protocol watchers लगभग चार वर्षों से नज़र रखे हुए थे: Monero अपनी transaction layer के सबसे गहरे rewrite की तैयारी कर रहा है, और यह 2017 में RingCT लागू होने के बाद का सबसे बड़ा बदलाव है। Seraphis कोई साधारण feature upgrade नहीं है। यह पूरे transaction protocol को बदल देता है, sender ambiguity की रक्षा करने वाले cryptographic proofs को बदलता है, और wallet level पर दिखने वाली addressing scheme को भी पुनः परिभाषित करता है। Jamtis, जो Seraphis के ऊपर चलने के लिए डिज़ाइन की गई addressing layer है, उस subaddress format को retire करता है जो पिछले आधे दशक से हर Monero wallet का आधार रहा है।

यह गाइड दोनों को समझाती है — ये क्या हैं, क्यों मुख्य researchers (koe, jberman, UkoeHB) ने हज़ारों घंटे इन्हें बनाने में लगाए, सामान्य users के लिए क्या बदलेगा, और MoneroSwapper जैसी no-KYC सेवा इस migration को बिना customers को private spending दोबारा सीखे संभालती है। यदि आपने कभी XMR भेजा या प्राप्त किया है, तो आपने जिस address का उपयोग किया था वह अंततः deprecated हो जाएगा। अभी upgrade समझना activation day पर हड़बड़ी करने से कहीं सस्ता है।

Monero को Seraphis की ज़रूरत क्यों पड़ी

Monero का वर्तमान transaction protocol कई परतों वाला patchwork है। आधार proof, CLSAG, ने अक्टूबर 2020 के hard fork में MLSAG की जगह ली और ring signature size को लगभग 25% तक कम कर दिया, लेकिन यह अब भी सोलह decoys के एक fixed ring पर काम करता है जो हाल के outputs से sampled होते हैं। सोलह-में-से-एक सुनने में मज़बूत लगता है, फिर भी statistical heuristics, timing analysis, और तथाकथित "EAE attack" (eve-alice-eve) adversarial models में sender anonymity को धीरे-धीरे कमज़ोर करते हैं। Researchers ने 2019 के बाद से कई peer-reviewed papers प्रकाशित किए हैं जो दिखाते हैं कि व्यापक mempool visibility रखने वाला एक well-funded analyst outputs के एक non-trivial हिस्से को probabilistically deanonymize कर सकता है।

Fungibility का तर्क समस्या को और बढ़ाता है। हर CLSAG ring में एक वास्तविक spend और पंद्रह decoys होते हैं, लेकिन वे decoys स्वयं पिछले transactions के outputs हैं। यदि दो transactions एक-दूसरे को decoys के रूप में reference करते हैं, और chain analysis किसी एक संभावना को बाहर कर सकती है, तो दूसरे के विरुद्ध probability तेज़ हो जाती है। यह system aggregate में मज़बूत है लेकिन किनारों पर leak करता है। Seraphis इस leak को बंद करता है — anonymity set को नाटकीय रूप से चौड़ा करके और proof को इस तरह restructure करके कि membership और ownership अलग हो जाएँ।

• बड़ा anonymity set: Seraphis को 128 या 256 outputs (या और भी अधिक, activation पर चुने गए curve और proof system के अनुसार) पर membership proofs को support करने के लिए डिज़ाइन किया गया है, न कि सिर्फ़ 16। गणित proof size में logarithmic है, इसलिए 128-में-से CLSAG के 16-में-से की तुलना में केवल थोड़े अधिक bytes लेता है।
• चिंताओं का स्पष्ट विभाजन: आज, एक एकल CLSAG proof "मैं इन outputs में से एक का स्वामी हूँ" को "मैंने इसे पहले से spend नहीं किया" के साथ जोड़ता है। Seraphis इन्हें एक membership proof और एक composition proof में अलग करता है। प्रत्येक को स्वतंत्र रूप से optimize, audit और upgrade किया जा सकता है।
• View-key surgery: वर्तमान view key हर incoming output को उसके धारक को दिखाती है। Auditors, exchanges, और tax accountants — सबको एक ही firehose मिलती है। Seraphis tiered view keys लाता है, ताकि user रसीदों तक read-only access दे सके बिना change outputs या self-spends को उजागर किए।
• Plug-in proofs: Seraphis architecture membership proofs को swappable मानता है। वर्तमान लक्ष्य FCMP++ (Full-Chain Membership Proofs Plus Plus) है, जो chain के हर output को एक संभावित decoy के रूप में काम करने देगा। यह सोलह से एक step-function छलांग है।

इसका मतलब यह नहीं है कि CLSAG आज टूटा हुआ है। इसका मतलब है कि design space आगे बढ़ गया है, academic cryptography परिपक्व हो गई है, और Monero की research culture "काफ़ी अच्छा" को तब स्वीकार नहीं करती जब "साबित रूप से बेहतर" मेज़ पर हो। कीमत है engineering complexity और एक multi-year transition; लाभ है एक privacy posture जो analysis tooling के अगले दशक तक टिकेगी।

Seraphis Transactions को कैसे बदलता है

Seraphis एक transaction protocol है, कोई एकल primitive नहीं। यह समझने के लिए कि क्या बदलता है, यह सहायक है कि आप देखें कि आज XMR भेजते समय क्या होता है और हर step को Seraphis के equivalent के साथ contrast करें। अंतर user experience में सूक्ष्म हैं लेकिन hood के नीचे गहरे हैं।

CLSAG से Composition + Membership Proofs तक

CLSAG के तहत, आपका wallet chain से पंद्रह decoys चुनता है, सोलह का एक ring बनाता है, और एक proof sign करता है जो कहता है कि उन सोलह में से एक आपका है और आपने double-spend नहीं किया। Seraphis के तहत, आपका wallet दो अलग proofs बनाता है। एक composition proof कहता है "मैं इस set के एक specific output का वैध स्वामी हूँ, और यह रहा matching key image जो साबित करता है कि मैंने इसे पहले spend नहीं किया है।" एक membership proof कहता है "जिस output का मैं reference कर रहा हूँ वह chain पर इस बड़े anonymity set में मौजूद है।" दोनों proofs cryptographically जुड़े हैं लेकिन स्वतंत्र रूप से generate होते हैं, और यही बात बाद में पूरे transaction format को redesign किए बिना anonymity set को expandable बनाती है।

Key images स्वयं भी redesign होती हैं। आज की key image one-time output key और spend key से deterministically derive होती है — एक चतुर निर्माण, लेकिन वर्षों से edge-case research का केंद्र। Seraphis एक नई key image format लाता है जो FCMP++ के साथ forward-compatible है, वही membership proof system जिसके बारे में Monero researchers आशा करते हैं कि वह अंततः anonymity set को chain के पूरे UTXO set तक फैलाने देगा।

Carrot: Output Encoding Layer

Carrot Seraphis के साथ डिज़ाइन की गई output encoding scheme है। जहाँ आज के outputs recipient की public view key और transaction-specific shared secret से derive एक stealth address का उपयोग करते हैं, Carrot outputs view-balance keys, internal-vs-external markers, और forward-secrecy hints जैसी चीज़ों के लिए नए fields जोड़ते हैं। व्यावहारिक परिणाम यह है कि wallet scanning तेज़ हो जाती है (क्योंकि internal outputs — आप अपने को भेजी गई change — पूरी decryption के बिना पहचाने जा सकते हैं) और view-key auditing सुरक्षित हो जाती है (क्योंकि auditor केवल वही देखता है जो user authorize करता है)।

Carrot डिफ़ॉल्ट रूप से "Janus protection" को भी encode करता है। Janus attack वह है जब एक malicious sender ऐसा output बनाता है जो उसे बाद में यह साबित करने देता है कि दो recipient addresses में से किसने funds प्राप्त किए। वर्तमान Monero protocol इसे एक subaddress check से रोकता है, लेकिन Carrot prevention को output format में ही पकाता है, बग्स के एक पूरे वर्ग को wallet-policy level के बजाय cryptographic level पर समाप्त करता है।

Transaction Size और Fees

आलोचक अक्सर पूछते हैं कि क्या Seraphis का मतलब बड़े transactions और ऊँचे fees हैं। ईमानदार उत्तर: संभवतः हाँ, थोड़ा सा, अल्पकाल में — और संभवतः नहीं, अंततः। प्रारंभिक Seraphis proofs CLSAG से बड़े हैं, configuration के आधार पर शायद 1.5x से 2x तक। लेकिन Monero का dynamic block size का अर्थ है कि fees congestion के साथ scale होते हैं, raw byte count के साथ नहीं, और Bulletproofs+ ने 2022 में पहले ही range proofs को आक्रामक रूप से सिकोड़ दिया था। एक बार FCMP++ आ जाने और anonymity set chain-wide scale तक फैल जाने पर, byte cost per unit of privacy आज की तुलना में गिर जाएगी।

Jamtis: वह Addressing Layer जो आप वास्तव में देखेंगे

Seraphis engine है। Jamtis dashboard है। अधिकांश users कभी composition proof नहीं पढ़ेंगे, लेकिन हर user एक Monero address copy और paste करेगा। Jamtis उस address को — और उसके पीछे की keys को — इस तरह redesign करता है कि Seraphis के privacy gains इस बात में प्रतिबिंबित हों कि wallets, exchanges और merchants network के साथ कैसे interact करते हैं।

वर्तमान Monero addresses base58 के 95 characters हैं जो mainnet primary addresses के लिए "4" से या subaddresses के लिए "8" से शुरू होते हैं। वे एक public spend key और एक public view key encode करते हैं, और बस। Jamtis addresses लंबाई में थोड़े छोटे या तुलनीय हैं (अंतिम format अभी भी protocol level पर तय किया जा रहा है) लेकिन काफ़ी अधिक संरचना encode करते हैं: एक address index, address type के लिए एक flag (main, exchange, integrated, या "auxiliary"), और authentication tags जो कुछ phishing और substitution attacks को रोकते हैं।

View-key tiering विशेष ध्यान के योग्य है क्योंकि यह एक वास्तविक pain point को solve करता है। आज, यदि आप अपनी view key एक accountant को देते हैं, तो वे हर output देखते हैं जो आपने कभी प्राप्त किया है — जिसमें आपके अपने spending से change, आपके अपने subaddresses के बीच payments, और कोई भी auxiliary income शामिल है। Jamtis आपको केवल वह विशिष्ट tier देने देता है जिसकी auditor को आवश्यकता है। एक "find-received" key incoming payments को amounts के बिना दिखाती है। एक "view-incoming" key incoming payments को amounts के साथ दिखाती है लेकिन change के बिना। एक "view-balance" key compliance reporting के लिए spendable balance दिखाती है बिना individual transactions को unmask किए। केवल "view-all" key, जिसे user निजी रखता है, सब कुछ देखती है।

MoneroSwapper जैसी सेवाओं के लिए जिन्हें customer के deposit की पुष्टि करनी होती है बिना उनके व्यापक wallet history को जाने, नई tiered structure का मतलब है साफ़ integrations और default रूप से मज़बूत privacy। Swap service यह verify कर सकती है कि "आपने सहमत राशि सहमत address पर भेजी" बिना customer के full balance, change pattern, या अन्य inbound activity में visibility रखे। यह मायने रखता है क्योंकि metadata का हर byte जो एक privacy-preserving service collect नहीं करती, वह byte है जिसके लिए उसे subpoena नहीं किया जा सकता, जिसके through leak नहीं हो सकता, या जिसे socially engineer करके निकाला नहीं जा सकता।

यदि आप एक privacy upgrade को एक वाक्य में वर्णित कर सकते हैं, तो वह लगभग निश्चित रूप से बहुत सरल है। Seraphis और Jamtis मिलकर एक system हैं: proofs, encoding, addresses, key hierarchy, और wallet UX सब मिलकर coordination में चल रहे हैं। इन्हें एक feature list के बजाय एक package के रूप में देखें।

Migration Path: अपना Wallet कैसे तैयार करें

Seraphis hard fork अभी तय नहीं है; Monero Research Lab और core team activation dates के बारे में जान-बूझकर रूढ़िवादी हैं, और कैलेंडर deadlines से "ready when ready" को प्राथमिकता देते हैं। पिछले Monero hard forks ने users को दो से छह महीने का notice दिया है, और complexity को देखते हुए Seraphis लगभग निश्चित रूप से उस range के लंबे छोर पर आएगा। यह रही एक practical preparation checklist जो activation week की सटीक तारीख़ की परवाह किए बिना लागू होती है।

1. अपने seed format का audit करें। यदि आपका wallet अभी भी legacy 25-word seed का उपयोग करता है, तो upgrade से पहले 16-word Polyseed-backed wallet में migrate करने पर विचार करें। Polyseed Jamtis derivation paths के साथ forward-compatible है; legacy seed को fork time पर एक wallet-side conversion step की आवश्यकता होगी।
2. Fork से पहले अपना wallet software कम से कम दो बार update करें। Monero GUI, CLI, Feather Wallet और Cake Wallet teams सामान्यतः कई pre-fork releases ship करती हैं। Activation से पहले के महीने से official Monero release notes और अपने wallet के changelog पर नज़र रखें — केवल auto-updates पर निर्भर न रहें, क्योंकि कुछ wallets major upgrades को manual confirmation के पीछे gate करते हैं।
3. एक spare device पर seed से full restore practice करें। किसी भी बड़े protocol upgrade से पहले, सबसे मूल्यवान risk control यह verify करना है कि आपका लिखा हुआ seed वास्तव में आपके funds को restore करता है। एक clean Monero CLI या Feather Wallet को एक अलग machine पर चलाएँ, seed से restore करें, और पुष्टि करें कि balance मेल खाता है। यह दो बार करें। यह हर छह महीने में करें, upgrades के बाहर भी।
4. अपने subaddress sprawl को पहचानें और कम करें। जिन users ने organizational उद्देश्यों के लिए दर्जनों subaddresses का उपयोग किया है (एक प्रति counterparty, एक प्रति merchant, आदि) उनका migration थोड़ा अधिक जटिल होगा। Fork से पहले funds को कम subaddresses के एक छोटे set में consolidate करना — और प्रत्येक को अपने wallet में स्पष्ट रूप से label करना — post-fork mental model को बहुत सरल बनाता है।
5. अपने view-key sharing relationships को document करें। यदि आपने अपनी view key किसी accountant, exchange, या audit tool के साथ साझा की है, तो लिखें कि किसके पास है और क्यों। Jamtis activate होने के बाद, आप संभवतः उन relationships को legacy full view key के बजाय नई tiered keys का उपयोग करने के लिए rotate करना चाहेंगे।
6. "Post-fork sweep" guidance पर नज़र रखें। पिछले Monero upgrades ने कभी-कभी users को outputs को पुराने format से नए format में "sweep" करने की आवश्यकता दी है, इससे पहले कि वे spendable हो जाएँ। Monero core team यदि Seraphis के लिए यह आवश्यक है तो स्पष्ट निर्देश publish करेगी; forums या social media की अफ़वाहों पर कार्य न करें।

No-KYC swap services के users के लिए, operational impact आमतौर पर न्यूनतम है। एक well-designed service protocol transition को abstract करती है: आप इसे address देते हैं, यह आपको XMR देती है, और यह Seraphis-vs-pre-Seraphis output formats को backend पर संभालती है। MoneroSwapper, उदाहरण के लिए, destination address के protocol version को एक customer-facing complication के बजाय एक routing decision मानता है। Customers वही workflow का उपयोग करते रह सकते हैं जो वे हमेशा करते आए हैं।

एक व्यावहारिक उदाहरण: नए Model में Swap प्राप्त करना

2026 के मध्य का एक सामान्य scenario पर विचार करें, यह मानते हुए कि Seraphis तब तक activate हो चुका है। मुंबई में एक user बिना KYC के Bitcoin को Monero में swap करना चाहता है। वह MoneroSwapper जैसी swap service पर जाता है, अपना Jamtis receiving address paste करता है (Feather जैसे updated wallet या official Monero GUI से generate किया हुआ), और प्रदान किए गए deposit address पर Bitcoin भेजता है।

पर्दे के पीछे, swap service Bitcoin को अपने liquidity pool के through route करती है, Monero acquire करती है, और user के Jamtis address पर सहमत राशि भेजने वाला एक Seraphis transaction construct करती है। Transaction में एक composition proof, 128-output (या बड़े) anonymity set से draw करता एक membership proof, और एक Carrot-encoded output शामिल है जिसे user का wallet single scan pass में पहचान सकता है। User को सामान्य 10 से 20 मिनट की confirmation window के भीतर अपने wallet में funds दिखाई देते हैं।

User के दृष्टिकोण से क्या बदला? कुछ भी दिखाई देने वाला नहीं। Hood के नीचे क्या बदला? Anonymity set परिमाण के एक क्रम से बढ़ा, output encoding अब protocol level पर Janus attacks का प्रतिरोध करती है, और swap service को कभी कोई ऐसी key नहीं मिली जो उसे user की व्यापक Monero activity के बारे में कुछ भी सीखने देती। System ने अधिक privacy work किया, transparent रूप से। यही एक well-executed protocol upgrade का लक्ष्य है: user को अदृश्य, auditor को प्रदर्शनीय रूप से मज़बूत।

Monero ecosystem के बाहर से आने वाले users के लिए — privacy के बारे में जिज्ञासु Bitcoiners, या नए privacy-coin adopters — Seraphis युग संभवतः उनका पहला exposure होगा। उन्हें कभी पता नहीं चलेगा कि सोलह-में-से-एक ring signatures के साथ जीवन कैसा था, जैसे आज के users शायद ही pre-RingCT दिनों को याद करते हैं जब transaction amounts chain पर public थे। यही है कि protocol upgrades को कैसा महसूस होना चाहिए: एक शांत सुधार जो नया baseline बन जाता है।

FAQ

Seraphis और Jamtis Monero mainnet पर कब activate होंगे?

कोई firm तारीख़ घोषित नहीं की गई है। Monero Research Lab और core team ने बार-बार कहा है कि activation cryptographic audits के पूरा होने, library hardening, major implementations पर wallet integration, और कम से कम एक full testnet cycle पर निर्भर करता है। 2025 के अंत में contributors के सार्वजनिक अनुमान 2026 के अंत से 2027 के मध्य तक थे, लेकिन project की culture स्पष्ट रूप से security-critical upgrades के लिए calendar-driven shipping को अस्वीकार करती है। आधिकारिक timing के लिए official Monero release notes और Monero Research Lab meeting logs पर नज़र रखें।

क्या मेरा वर्तमान Monero address upgrade के बाद भी काम करेगा?

हाँ, एक transitional period के लिए। Monero में hard forks ने ऐतिहासिक रूप से backward-compatible address handling शामिल किया है ताकि legacy addresses पर भेजे गए funds अभी भी पहुँचें। लंबे समय में, wallet software users को Jamtis addresses पर migrate होने के लिए encourage करेगा, और अंततः नए wallets legacy addresses generate करना पूरी तरह बंद कर सकते हैं। वर्तमान addresses में रखे funds के लिए कोई तत्काल "deadline" risk नहीं है, लेकिन आप fork time के आसपास अपने wallet software को update करना चाहेंगे।

क्या Seraphis Monero की tail emission या supply schedule बदलता है?

नहीं। Seraphis एक transaction-layer protocol upgrade है। यह monetary policy को नहीं छूता। 0.6 XMR per block की tail emission अपरिवर्तित जारी रहेगी। Total emission curve, block reward dynamics, और RandomX proof-of-work algorithm सभी Seraphis से अलग हैं और upgrade से प्रभावित नहीं हैं।

क्या Seraphis Trezor और Ledger जैसे hardware wallets के साथ compatibility तोड़ेगा?

Hardware wallet vendors को नए proof formats और key derivation paths को support करने के लिए अपने firmware को update करना होगा। ऐतिहासिक रूप से, Trezor और Ledger दोनों ने hard fork timelines के अनुसार Monero firmware updates ship किए हैं, हालाँकि कभी-कभी हफ़्तों या महीनों की देरी के साथ। Hardware wallets पर निर्भर users को fork time पर अपने device firmware को आँख बंद करके upgrade नहीं करना चाहिए — इसके बजाय, vendor से स्पष्ट पुष्टि का इंतज़ार करें कि नया firmware active Monero protocol version को support करता है, और transition window के लिए एक software-wallet backup capability रखें।

Seraphis अन्य privacy projects के approaches से कैसी तुलना करता है?

Zcash पूरी तरह shielded transactions के लिए zk-SNARKs का उपयोग करता है, जो मज़बूत theoretical privacy देते हैं लेकिन ऐतिहासिक रूप से एक trusted setup ceremony की आवश्यकता होती थी और adoption बहुत कम है (अधिकांश Zcash volume transparent है)। Grin जैसी Mimblewimble chains output aggregation पर आधारित एक मौलिक रूप से अलग model का उपयोग करती हैं, जो compactness के लिए कुछ auditability का बलिदान देती है। Seraphis Monero के मौजूदा model के भीतर रहता है — ring signatures और stealth addresses — लेकिन design को इसकी practical maximum तक ले जाता है। Trade-off engineering complexity है, बदले में कोई trusted setup नहीं और आज के Monero के साथ निरंतर एक smooth user experience।

क्या मैं fork activate होने से पहले MoneroSwapper पर Jamtis addresses में swap कर सकता हूँ?

नहीं, क्योंकि Jamtis addresses अभी वर्तमान production wallets द्वारा generate नहीं किए जा सकते। एक बार protocol activate हो जाने और Monero GUI, Feather, और Cake Wallet जैसे major wallets Jamtis support रोल आउट कर देने के बाद, swap services transition window के दौरान legacy addresses के साथ नए address format को स्वीकार करेंगी। तब तक, आपका मौजूदा Monero address सभी swap activity के लिए सामान्य रूप से काम करता रहेगा।

निष्कर्ष

Seraphis और Jamtis Monero की उस प्रतिबद्धता का प्रतिनिधित्व करते हैं जिसमें वह analysis curve से आगे रहना चाहता है, उस पर प्रतिक्रिया करने के बजाय। यह upgrade चमकदार नहीं है, price-pump narrative पैदा नहीं करेगा, और दिन-प्रतिदिन users जो करते हैं उसे नाटकीय रूप से नहीं बदलेगा। यह जो करेगा वह है network की privacy floor को काफ़ी ऊँचा करना, users को बारीक नियंत्रण देना कि वे क्या प्रकट करते हैं और किसे, और Monero development के अगले दशक के लिए cryptographic आधार बिछाना। यदि आप XMR रखते हैं या इसे रोज़मर्रा के privacy-preserving payments के लिए उपयोग करते हैं, तो अगले छह से बारह महीने अपने seed format को update करने, अपने wallet software habits को refresh करने, और अपनी restore process को verify करने में लगाएँ। जब fork आए, तो आप चाहते हैं कि यह एक non-event हो। आज ही एक no-KYC, no-account swap service के साथ Monero का उपयोग शुरू करने के लिए जो Seraphis transition को transparent रूप से संभालेगी, MoneroSwapper पर जाएँ और मिनटों में अपनी मौजूदा crypto को XMR में exchange करें।