ब्रह्मांडीय पैमाने के यूनिक ID

 (jasonfantl.com)
25 पॉइंट द्वारा GN⁺ 2026-02-20 | 4 टिप्पणियां | WhatsApp पर शेयर करें
  • डिवाइस या ऑब्जेक्ट्स को बिल्कुल भी डुप्लिकेट न होने वाला ID देने के तरीकों की पड़ताल की गई है, और random तथा deterministic तरीकों की तुलना की गई है
  • random तरीका काफी बड़े bit-size का उपयोग करने पर collision की संभावना को व्यावहारिक रूप से 0 के करीब ला सकता है, और इसमें UUID (122-बिट) से लेकर पूरे ब्रह्मांड की computational limit (798-बिट) तक कई स्तर शामिल हैं
  • deterministic तरीके में central counter, delegated hierarchy (Dewey), binary tree (Binary), token (Token) जैसी कई schemes प्रस्तावित की गई हैं, और हर तरीके की ID length growth characteristics का simulation के जरिए विश्लेषण किया गया है
  • यह गणितीय प्रमाण भी दिया गया है कि सभी deterministic schemes worst case में linear growth से बच नहीं सकतीं
  • नतीजतन, ब्रह्मांडीय विस्तार के स्तर पर भी व्यावहारिक और कुशल तरीका random ID generation ही है, जबकि deterministic तरीके अक्षम साबित होते हैं

यूनिक ID की ज़रूरत और समस्या की रूपरेखा

  • ऑब्जेक्ट पहचान manufacturing, logistics, communication, security जैसे सभी systems की बुनियाद है, और बड़े पैमाने पर विस्तार होने पर बिना duplication वाले ID देना एक मुख्य चुनौती बन जाता है
  • अगर मानव सभ्यता आकाशगंगा स्तर तक फैलती है, तब भी डुप्लिकेट-रहित ID system की आवश्यकता होगी
  • समस्या को इस तरह रखा गया है: “ऐसा ID कैसे बनाया जाए जो कभी भी डुप्लिकेट न हो?”

random तरीका

  • सबसे सरल तरीका है कोई भी random संख्या चुन लेना
    • इसे कहीं से भी, बिना central management या synchronization के generate किया जा सकता है
  • collision की संभावना को bit-size बढ़ाकर नियंत्रित किया जा सकता है, और इसे व्यावहारिक रूप से 0 के बहुत करीब लाया जा सकता है
  • UUID (122-बिट) में लगभग $2^{61}$ IDs generate होने पर collision की उम्मीद की जा सकती है
  • पूरे ब्रह्मांड की computational limit (10¹²⁰ बार) को ध्यान में रखें तो 798-बिट की आवश्यकता होगी
    • atomic scale (10⁸⁰ इकाइयाँ) के लिए 532-बिट, और 1g nanobots (10⁵⁶ इकाइयाँ) के लिए 372-बिट
  • वास्तविक randomपन सुनिश्चित करना महत्वपूर्ण है, इसलिए CSPRNG या quantum random source के उपयोग की सिफारिश की गई है
    • सामान्य seed या constant ID (जैसे all-zero) पर रोक ज़रूरी है

deterministic तरीका

  • central counter तरीके में एक single server क्रमवार IDs जारी करता है
    • accessibility की समस्या के कारण satellite-डिवाइस delegation structure (Dewey) प्रस्तावित किया गया है
  • Dewey scheme: A.B.C रूप का hierarchical ID, जिसे Elias omega coding से व्यक्त किया जाता है
    • tree structure के आधार पर इसमें logarithmic या linear growth होती है
  • Binary scheme ID space को binary tree में विभाजित करती है, और कुछ स्थितियों में Dewey से अधिक कुशल होती है
  • 2-Adic Valuation गणितीय uniqueness की गारंटी देता है, और यह Binary का एक परिवर्तित रूप है
  • Token scheme chain structure में logarithmic growth दिखाती है, लेकिन चौड़ाई बढ़ने पर linear में बदल जाती है

linear growth की अनिवार्यता का प्रमाण

  • यह मानकर कि ID आवंटन का हर path अद्वितीय होना चाहिए, संभव paths की संख्या की गणना की गई है
  • जब nodes की संख्या n हो, तो आवश्यक IDs की संख्या $2^{n-1}$ तक बढ़ती है
  • इसलिए ID length कम-से-कम O(n) होगी, यानी worst case में linear growth अनिवार्य है
  • कोई भी algorithm हर स्थिति में logarithmic growth बनाए नहीं रख सकता

विस्तार मॉडल simulation

  • Random Recursive Tree, Preferential Attachment, Fitness Model जैसे कई growth models पर प्रयोग किए गए
    • छोटे पैमाने (2,048 nodes) पर Binary बेहतर रहा, जबकि Dewey और Token का प्रदर्शन स्थिति पर निर्भर था
    • Preferential model में Dewey सबसे कुशल रहा
    • Fitness model में Dewey और Binary का प्रदर्शन लगभग समान था
  • दस लाख nodes के पैमाने पर भी Dewey और Token ने logarithmic growth बनाए रखी
    • ID length को लगभग 6.55 × ln(n) के रूप में निरूपित किया जा सकता है

आकाशगंगा और ब्रह्मांडीय पैमाने का विस्तार मॉडल

  • ग्रहों के बीच प्रसार को एक निश्चित गति वाले wave front के रूप में model किया गया है
    • हर ग्रह लगभग 10⁹ IDs generate करने के बाद अगले ग्रह तक फैलता है
  • आकाशगंगा की त्रिज्या लगभग 2,121 ग्रह मानी गई, और पूरे प्रसार पर ID length लगभग 288,048-बिट हुई
  • आकाशगंगाओं के बीच प्रसार (लगभग 7,816 चरण) तक विचार करने पर लगभग 2.2 अरब बिट (281MB) की आवश्यकता पड़ती है
  • deterministic तरीके अक्षम हैं, और random तरीका (798-बिट या कम) बेहद अधिक कुशल है

सुरक्षा और अतिरिक्त विचार

  • ID forgery रोकने के लिए signature-based verification system लागू किया जा सकता है
    • random IDs में public key को ID की तरह इस्तेमाल किया जा सकता है, जबकि deterministic scheme में parent child key पर signature करता है
  • error-correcting code और version management की आवश्यकता है
  • ऐसी वस्तुएँ जिनमें ID store नहीं किया जा सकता (जैसे ग्रह), उन्हें कई IDs की mapping से प्रबंधित किया जा सकता है
  • Theseus के जहाज़ की समस्या की तरह, components बदलने पर ID बना रहना चाहिए या नहीं, इस पर भी चर्चा है
  • संबंधित अवधारणाएँ: Decentralized Identifiers (DID), Ancestry Labeling Schemes

निष्कर्ष

  • deterministic schemes सैद्धांतिक रूप से रोचक हैं, लेकिन व्यावहारिकता कम है
  • random ID generation ब्रह्मांडीय पैमाने पर भी वास्तविक और कुशल है
  • ID collision की संभावना को “व्यावहारिक रूप से 0” तक ले जाना ही सबसे सुरक्षित और उपयोगी विकल्प है

संबंधित पढ़ाई

4 टिप्पणियां

 
princox 2026-02-20

समय-आधारित तरीके से बनाना हो तो उसे रैखिक ही मानना चाहिए, है न..?
लगता है मूल लेख थोड़ा देखना पड़ेगा। दिलचस्प कहानी है।
 
mammal 2026-02-20

मूल लेख ज़रूर पढ़िए। उसमें फ़ॉर्मूला और simulation के ज़रिए visual तरीके से समझाया गया है, इसलिए पढ़ने में बहुत मज़ा आया।
 
hmmhmmhm 2026-02-20

अगर टकराव हो जाए, तो क्या वह ब्रह्मांडीय स्तर की बदकिस्मती होगी...(?)
 
GN⁺ 2026-02-20
Hacker News टिप्पणियाँ

  • यह विश्लेषण पूरी तरह निष्पक्ष नहीं है। UUID डिज़ाइन करते समय locality यानी प्रकाश की गति को ध्यान में रखा जाता है, लेकिन collision probability की गणना में इसे नज़रअंदाज़ किया गया है। वास्तव में collision का अर्थ तभी है जब दो UUID बनने के बाद causal contact में आएँ। इसलिए साधारण birthday paradox लागू करना गलत तरीका है। locality को ध्यान में रखें तो ज़रूरी UUID size लेख में बताए गए 800-bit से बहुत छोटा होगा। मैंने गणितीय हिसाब नहीं लगाया, लेकिन यह 256-bit से ज़्यादा नहीं होगा, ऐसा लगता है। HN उन गिने-चुने स्थानों में से है जहाँ ऐसी बारीक तकनीकी चर्चाएँ गंभीरता से होती हैं, इसलिए यह मुझे सच में पसंद है

    • मैंने पहले एक cosmic expansion hypothesis के बारे में पढ़ा था जिसमें galaxies इतनी दूर चली जाती हैं कि वे एक-दूसरे से जानकारी का आदान-प्रदान नहीं कर पातीं। उस hypothesis के अनुसार, intelligent life forms जीवित रहने के लिए सबसे अधिक mass density वाले स्थानों की ओर सिमटेंगी। अंततः universe की thermal death से पहले alien civilizations एक जगह इकट्ठा होने वाली किसी ‘महासभा’ जैसी घटना हो सकती है। तब तक शायद UUID collisions होने लगें। Vogon अगर हर XML tag पर UUID चिपकाएँ, तो statistics बर्बाद हो जाएँगे — ऐसी कल्पना की जा सकती है
    • मुझे याद है, एक बार मुझे Intel NICs का एक डिब्बा मिला था और उन सबका MAC address एक ही था। वजह ढूँढ़ने में कई दिन खराब हुए थे
    • जब हम बेहद कम probability की बात करते हैं, तब शायद हमें यह संभावना भी माननी चाहिए कि हम cosmology को गलत समझ रहे हों। हो सकता है light cone ही causal limit न हो
    • समय और locality दोनों को ध्यान में रखना चाहिए। proton के decay होने और matter के गायब हो जाने तक का समय भी केवल लगभग 10^56 nanoseconds है
    • यह आलोचना सही है। मूल लेख एक मज़ेदार thought experiment है, लेकिन causality को नज़रअंदाज़ करके समस्या को बढ़ा-चढ़ाकर दिखाता है। वास्तव में UUID collisions का मतलब केवल उन systems में है जो आपस में communicate करते हैं। ऐसे systems light cone तक सीमित होते हैं। 128-bit मानवता द्वारा हज़ार साल तक बनाए जाने वाले systems के लिए भी काफ़ी है, और 256-bit पूरे universe के लिए भी ज़रूरत से ज़्यादा है

  • addressable objects की संख्या निकालते समय यह भी ध्यान में रखना चाहिए कि हर object का address कम-से-कम एक बार कहीं न कहीं store होना पड़ेगा। अगर एक bit store करने के लिए Npb particles चाहिएँ, तो address bits बढ़ने के साथ addressable objects की संख्या घटती जाएगी। इसलिए Nthg = Np / (Npb * f(Ntng)) जैसे किसी संबंध से अधिकतम addressable objects की संख्या निकाली जा सकती है

  • एक बार मुझे यह दलील देनी पड़ी थी कि 256-bit random ID इतना काफ़ी है कि collision check की ज़रूरत ही नहीं है। साथियों का कहना था कि जटिल collision verification logic जोड़ना चाहिए, लेकिन मैंने समझाया कि 2^256 का पैमाना observable universe में atoms की संख्या के आसपास है। collision होने से पहले data center के लाखों बार फट जाने की संभावना ज़्यादा है — ऐसा कहकर मनाना पड़ा। अंत में हम इस नतीजे पर पहुँचे कि 128-bit भी काफ़ी है

    • लेकिन अगर distributed environment में untrusted parties ID बना रही हों, तो malicious collision की संभावना रहती है, इसलिए verification ज़रूरी है। वहीं single system में एक साधारण counter ही काफ़ी है, और कई servers हों तो sharded counter से ranges बाँटी जा सकती हैं
    • दरअसल हिसाब इससे भी आसान है। पूरी मानवता के डेटा की कुल मात्रा अभी 1 yottabyte भी नहीं है। birthday paradox के मुताबिक 50% collision probability लगभग 2^128 entries पर आती है। 256-bit ID का आकार 32 bytes है, इसलिए 2^128 * 32 bytes = 10^16 yottabytes चाहिएँगे। यानी collision probability खगोलीय रूप से कम है

  • एक गणना के मुताबिक अगर हर atom को ID देना हो तो लगभग 532 bits चाहिएँगे। लेकिन व्यवहार में आप atoms के समूहों, जैसे microchip, car आदि, को भी ID देना चाहेंगे, इसलिए संख्या और बढ़ सकती है

    • असल में हर particle को नहीं, बल्कि हर particle type के लिए एक ही ID काफ़ी होगी। physics के नियमों के अनुसार एक जैसे particles अलग-अलग पहचाने नहीं जा सकते
    • atom groups को शामिल करने पर भी अतिरिक्त bits लगभग नगण्य ही बढ़ेंगे
    • क्या UUIDv∞ कम-से-कम 536-bit का होगा? अगर group ID या timestamp भी जोड़ें तो शायद 1024-bit तक पहुँच जाए
    • neutrino हर बार oscillate करे तो क्या उसे नई ID देनी होगी? शुक्र है, electron के लिए एक ही काफ़ी है

  • card deck से ID व्यक्त करने का एक विचार है। 52 cards में से हर एक को Unicode character से दिखाया जाए तो वह पढ़ने में आसान होगा, हाथ से edit करना कठिन होगा, और pattern recognition में भी मदद मिलेगी। असली card deck को shuffle करके camera से पढ़ा जाए तो उसे random seed के रूप में भी इस्तेमाल किया जा सकता है। इसी तरह का एक विचार DiceKeys भी है

    • लेकिन “ठीक से shuffle करना” ही इसकी सबसे बड़ी कमजोरी है

  • शानदार visualization और insight है। मैंने database को यथासंभव छोटे random identifiers के इर्द-गिर्द डिज़ाइन किया है। मुझे लगता है कि ऐसे universal identifiers ही असल में एकमात्र ‘golden disk’ हैं। scientific data management या library science जैसे क्षेत्रों में इस विचार को कम आंका जाता है। बड़े संगठनों की कई समस्याएँ बेहतर identifier design से हल हो सकती थीं.
    संबंधित लेख: Identifiers Deep Dive, Trible Structure

    • entity की identity को intrinsic रूप से भी परिभाषित किया जा सकता है। फिर consistency contract क्यों नहीं?

  • मैं अभी Becky Chambers की The Galaxy, and the Ground Within के लगभग पेज 281 पर हूँ।
    किताब में संदेश का एक उदाहरण:

    Received Message
Encryption: 0
From: GC Transit Authority --- Gora System (path: 487-45411-479-4)
To: Ooli Oht Ouloo (path: 5787-598-66)
Subject: URGENT UPDATE

    मुझे यह series बहुत पसंद है। यह दिलचस्प है कि बहु-प्रजातीय universe में केंद्रीय रूप से सहमत path addressing system इस्तेमाल होता है

    • इसी तरह के उदाहरण के लिए Vernor Vinge की A Fire Upon The Deep की सिफारिश करूँगा। उसमें intergalactic communication labeling का तरीका दिलचस्प है
    • खासकर वह दृश्य यादगार था जहाँ cheese की अवधारणा से डर लगता है। इस series की दूसरी किताब A Closed and Common Orbit सबसे बेहतरीन थी

  • हाल ही में मुझे Snowflake ID के बारे में पता चला। इसका इस्तेमाल Twitter, Discord, Instagram, Mastodon आदि में होता है। यह timestamp + random के संयोजन से ID size घटाने का तरीका है, लेकिन अफ़सोस कि लेख में इसका ज़िक्र नहीं था।
    Snowflake ID wiki, Tom Scott वीडियो देखें।
    अगर Snowflake timestamp के कुछ bits को random से बदल दिया जाए, तो शायद प्रति सेकंड 4 अरब IDs बनाई जा सकती हैं

    • असल में Snowflake की संरचना UUID v1 से लगभग वही है। बस उसका आकार आधा है
    • इसी तरह का एक विचार DRUUID भी है
    • लेकिन पूरे universe का एक ही clock पर सहमत होना लगभग असंभव है
    • यह तरीका BSON ID से भी मिलता-जुलता है

  • मुझे जिज्ञासा है कि क्या observable phenomena के आधार पर ID बनाई जा सकती है। समय और दूरी से अलग-अलग होने वाली विशेषताओं के कारण शायद uniqueness सुनिश्चित हो सके। उदाहरण के लिए, किसी खास समय पर तारों की रोशनी का pattern शायद केवल एक ही व्यक्ति देख सकता है। यह lava lamp से noise लेकर entropy बनाने जैसा है। अगर पूरे universe का coordinate system परिभाषित किया जा सके, तो local time + x + y + z + salt के संयोजन से unique ID बनाई जा सकती है

  • random UUID तरीका longevity के लिहाज़ से कहीं बेहतर है। एक ही समय पर सक्रिय रह सकने वाले devices की संख्या सीमित होती है, और tree-based UUIDs के विपरीत, device हट जाने पर ID को reuse किया जा सकता है। व्यवहार में location-based root + random lower bits मिलाने वाला hybrid algorithm सबसे व्यावहारिक लगेगा