BITCOIN

DNS का उपयोग करके बिटकॉइन पतों को सरल बनाना

यह मार्क जेफ्टोविक, ईज़ीडीएनएस टेक्नोलॉजीज इंक के सह-संस्थापक और सीईओ और “प्रबंधन मिशन क्रिटिकल डोमेन और डीएनएस” के लेखक द्वारा एक राय संपादकीय है। )

जिस क्षण से मैंने 2013 में बिटकॉइन की खोज की, मुझे पता था कि अंततः मानव-पठनीय लेबल का उपयोग करके वॉलेट पते को संदर्भित करने का एक तरीका होना चाहिए।

के साथ बड़ी समस्या बिटकॉइन के लंबे पते यह हैं कि वे यादगार नहीं हैं, और बिटकॉइन के छद्म नाम या अनाम विशेषताओं के बावजूद, बहुत बार आप आसानी से दावा करने या सत्यापित करने में सक्षम होना चाहते हैं कि एक वॉलेट पता एक विशिष्ट इकाई से संबंधित है – एक चैरिटी को दान के बारे में सोचें या एक क्राउडफंड। यह हर ब्लॉकचेन को प्रभावित करता है।

एक DNS (डोमेन नाम सिस्टम) आदमी के रूप में, मैंने यह फिल्म पहले भी देखी है: DNS का आविष्कार IPv4 एड्रेसिंग के साथ उसी समस्या को हल करने के लिए किया गया था। समय के साथ डीएनएस बहुत कुछ करने के लिए विकसित हुआ – न केवल डीएनएस ने आईपीवी 6 पते को हल करने की क्षमता को जोड़ा, बल्कि नामस्थान के बारे में मेटाडेटा को व्यक्त करने के लिए इसका तेजी से उपयोग किया जाता है। सोचें एसआरवी रिकॉर्ड, एनएपीटीआर , आरबीएल ब्लॉकलिस्ट, प्रतिक्रिया नीति क्षेत्र (आरपीजेड) ) और

सर्वव्यापी TXT रिकॉर्ड

(जिसका उपयोग SPF, DMARC, DKIM और किसी अन्य चीज़ के लिए किया जाता है जो मूल रूप से प्रोटोकॉल में फिट नहीं होता है)।

बिटकॉइन के साथ आता है और हमें एक ही समस्या है, बड़े लिखें।

बिटकॉइन और बिजली के लिए विशिष्ट समस्या

ऐसा लग रहा है कि भुगतान लेन-देन की अधिकांश गतिविधि लाइटनिंग जैसे प्रोटोकॉल के साथ लेयर 2 में चली जाएगी, और हाल ही में का आगमन) बिजली का पता

बिजली के पते LNURL पर भरोसा करते हैं

। -पे प्रोटोकॉल, और वे काफी हद तक एक ईमेल पते की तरह दिखते हैं:

के माध्यम से: https://github.com/andrerfneves/lightning-address/blob/master/README.md

ईमेल पता नामकरण पहचान की जानकारी देने का सही तरीका है। यह आसानी से संगठनों का सीमांकन करता है और इसके भीतर इकाइयों या लोगों को उप-विभाजित करता है। हर कोई पहले से ही इस प्रारूप के लिए अभ्यस्त है और जैसा कि हम देखेंगे, गंतव्य मेलबॉक्स की तुलना में बहुत अधिक जानकारी देने की क्षमता है।

वर्षों से मैं इस प्रारूप के लिए वास्तविक मानक बनने की उम्मीद कर रहा था। सत्र दीक्षा प्रोटोकॉल के साथ पहचान समापन बिंदु ( एसआईपी) और एक्सएमपीपी

एसआईपी और एक्सएमपीपी ने दुनिया भर में उस तरह से कब्जा नहीं किया जिस तरह से मैंने उनसे (कम से कम अभी तक नहीं) उम्मीद की थी और कुछ समय के लिए, पहचानकर्ताओं ने ट्विटर हैंडल और जीथब उपयोगकर्ता जैसे केंद्रीकृत प्लेटफार्मों की ओर बढ़ना शुरू कर दिया था। आईडी मैंने हमेशा यह विचित्र पाया, विशेष रूप से बिटकॉइनर्स के बीच। उस पर नीचे)।

केवल एक ही समस्या है: परिभाषित एलएनयूआरएल स्पेक में अमूर्तता का स्तर गुम है। इसके बिना, प्रकाश पतों के लिए उपयोग के मामले बहुत सीमित हो जाते हैं।

बिजली के पते को देखते हुए:

[email protected] the lightning address satoshi domain

इसका मतलब है कि वर्तमान विनिर्देश के तहत, भुगतान विवरणक यहां स्थित होगा:

the lightning address satoshi domainhttps://example.com/। जाने-माने/lnurlp/सतोशी/

लेकिन क्या होगा अगर सतोशी के पास example.com वेबसर्वर तक पहुंच नहीं है? अगर हम ईमेल पते के सादृश्य के साथ चिपके रहते हैं: सिर्फ इसलिए कि आपके पास यह आपके पते के रूप में है इसका मतलब यह नहीं है कि मेल खाने वाले होस्टनाम वाला सर्वर वह जगह है जहां ईमेल वितरित किया जाता है।

वास्तव में यह शायद नहीं है मामला अधिक बार होता है। इस कारण से डीएनएस में एमएक्स रिकॉर्ड प्रकार मौजूद है, जो ईमेल के लिए गंतव्य को नियंत्रित करने के लिए एक अतिरिक्त स्तर का संकेत जोड़ता है। वे पूरी तरह से अलग डोमेन नाम के तहत काम कर रहे होस्टनामों को ईमेल वितरण निर्देशित कर सकते हैं (उन लोगों के बारे में सोचें जो बाहरी ईमेल प्रदाता का उपयोग करते हैं, लेकिन अपने स्वयं के कस्टम डोमेन के साथ)।

एक ही बात होने की जरूरत है काफी हद तक समान कारणों से बिजली के पते के साथ। ‘@’ के दाईं ओर के होस्टनाम में वेबसर्वर बिल्कुल नहीं हो सकता है, या उपयोगकर्ता अनावश्यक रूप से एक लाइटनिंग एड्रेस का उपयोग करने के लिए सीमित है, जहां होस्टनाम घटक केवल उस वेबसर्वर का हो सकता है जहां JSON फ़ाइल होस्ट की गई है। लाइटनिंग एड्रेस प्रकाशित करते समय यह एक समस्या हो सकती है कि उपयोगकर्ता सड़क को बदलना चाहता है।

एक DNS आदमी के रूप में, समाधान स्पष्ट लग रहा था लेकिन मैं इसे खत्म करने का दोषी था:

2017 में मुझे उस समय एथेरियम नाम सेवा कार्य समूह द्वारा लंदन में एक बैठक में आमंत्रित किया गया था ताकि ईएनएस रजिस्ट्री के लिए विनिर्देश तैयार किया जा सके।

मैंने उस बैठक को यह सोचकर छोड़ दिया कि एक नया DNS संसाधन रिकॉर्ड होना चाहिए, एक नया रिकॉर्ड प्रकार जो विरासती DNS के भीतर से ब्लॉकचेन संसाधनों को संदर्भित करने में सक्षम होगा।

मेरे दिमाग में यह होगा एसआरवी या एनएपीटीआर रिकॉर्ड की तरह कुछ देखें, जिसमें प्रोटोकॉल, पोर्ट और वेटिंग के लिए अलग-अलग क्षेत्र थे (तथ्य यह है कि वेब ब्राउज़र आज भी वेब पतों के लिए एसआरवी रिकॉर्ड नहीं देखते हैं, यह इंटरनेट युग के महान छूटे हुए अवसरों में से एक है)।

इसके लिए मेरा काम करने वाला शॉर्टहैंड “ब्लॉकचैन पॉइंटर” के लिए “बीसीपीटीआर” था और इसमें वास्तव में कौन सा ब्लॉकचेन इंगित करने के लिए एक जटिल, जटिल विनिर्देश था एक रिकॉर्ड इंगित कर रहा था और यह किस प्रकार का संसाधन था।

फिर लाइटनिंग गिटहब मुद्दे में, जहां एलएनयूआरएल आरएफसी पर चर्चा की जा रही थी, कोई

“_lud16” उप डोमेन के साथ बस एक पता तैयार करने का सुझाव दिया।

कुछ नामकरण विशेषताओं को वास्तविक होस्टनाम से अलग करने के लिए अंडरस्कोर का उपयोग करना कुछ समय के लिए रहा है। इसका उपयोग मूल SRV RR कल्पना में किया गया था RFC2872 और बाद में “अंडरस्कोर स्कोपिंग” के रूप में वर्णित किया गया आरएफसी 8552

सुझाव मेरे दिमाग में तुरंत फट गया और मुझे एहसास हुआ कि मैं वर्षों से इस पर विचार कर रहा था।

DNS में एक स्कोप्ड लेबल, जैसे _tcp या _udp, केस असंवेदनशील होते हैं और हम उन्हें SIP, VOIP और ENUM अनुप्रयोगों में उपयोग के लिए SRV और NAPTR रिकॉर्ड में देखते हैं, लोड बैलेंसिंग, उल्लेख नहीं करने के लिए DKIM और DomainKeys के लिए TXT रिकॉर्ड में।

_lud16 या _btc जैसा कोई भी मान्य डीएनएस लेबल, हमें डीएनएस ट्री में पैरेंट नोड के तहत स्कोप से मेल खाने वाली क्वेरी की प्रतिक्रिया को सीमित करने के लिए एक तंत्र प्रदान करता है।

अर्थ:

$मूल example.com. _ie. TXT में परीक्षण “यह एक परीक्षा है”

_eg.test में TXT “यह एक अलग परीक्षण है”

“test.example.com” पर टाइप TXT के लिए DNS क्वेरी कोई जवाब नहीं देगी (NXDOMAIN)।

“_ie.test.example.com” पर टाइप TXT के लिए DNS क्वेरी केवल पहले रिकॉर्ड के लिए एक परिणाम लौटाएगी।

A “test._ie.example.com” पर टाइप TXT के लिए DNS क्वेरी केवल दूसरा रिकॉर्ड लौटाएगी।

दूसरे शब्दों में, हमारे पास है test.example.com लीफ के लिए कई TXT रिकॉर्ड, हालांकि, हम स्कोप्ड लेबल के साथ क्वेरी किए गए एक को ही लौटाएंगे, जो अंडरस्कोर से शुरू होता है।

यह पता चला है कि यह हमारे उद्देश्यों के लिए काफी शक्तिशाली है। यह हमारे उपयोग के मामले में सबसे आसान, इष्टतम समाधान भी है क्योंकि:
हर कोई इसका इस्तेमाल कर सकता है।

हम यहाँ से बिना वहाँ पहुँच सकते हैं पहले से मौजूद किसी भी चीज़ को तोड़ना: हों *) पहले से ही एलएनयूआरएल पते का उपयोग करने वाले एप्लिकेशन हमेशा इसका उपयोग कर सकते हैं होते )एप्लिकेशन DNS लुकअप जोड़ सकते हैं लेकिन डीएनएस है केंद्रीकृत!

यह सच है कि डीएनएस में एक उल्टा पेड़ संरचना है जो रूट “।” पर समाप्त होती है। लेकिन वह रूट भी काफी विकेंद्रीकृत है, जिसमें कम से कम 13 अलग-अलग ऑपरेटरों द्वारा संचालित हजारों सर्वर शामिल हैं। विरासती डीएनएस तार्किक रूप से केंद्रीकृत हो सकता है लेकिन वास्तव में यह एक तरह के विकेन्द्रीकृत संघ की तरह कार्य करता है।

यहां तक ​​कि यह बदल रहा है, विकसित हो रहा है। मुझे लगता है कि जहां हम अंत में समाप्त होते हैं, जहां नामस्थान मौजूदा उल्टे पेड़ की जड़ और पूरी तरह से विकेन्द्रीकृत ब्लॉकचेन दोनों को फैलाते हैं।

इनमें से कुछ पहले से ही आज यहां हैं: आप कुछ ऐसा उपयोग कर सकते हैं ढेर और .btc डोमेन जो बिटकॉइन को पिन करता है और संभवत: बिटकॉइन के ऊपर सीधे निर्मित अन्य नामस्थान होंगे। बहुत। एक नए पर भी काम किया जा रहा है

  • DNSresolvers कार्यान्वयन जो स्टैक, .btc, और HNS डोमेन को हैंडशेक और अनस्टॉपेबल टॉप-लेवल डोमेन द्वारा हल करेगा। आप अल्फ़ा.dnsresolvers.com पर लुकअप के माध्यम से इसका परीक्षण कर सकते हैं:

    % खुदाई + लघु Easydns.btc @alpha.dnsresolvers.com

    3.1.49.122

    (यह सर्वर अवधारणा का सबूत है और भविष्य में चला जाएगा,

  • कृपया इसे न जोड़ें आपके संकल्प के लिए।) यह सब, और यह हल करता है नकली ट्विटर हैंडल समस्या भी!

    एक बार जब हम इसे अंडरस्कोर स्कोपिंग का उपयोग करने के लिए एक सम्मेलन बनाते हैं, तो हम पाते हैं कि हम मौजूदा तरीकों का उपयोग करके सभी प्रकार की समस्याओं को हल कर सकते हैं।

    आइए नकली ट्विटर हैंडल की समस्या को देखें जो बिटकॉइन स्पेस को प्रभावित करती है।

    एक ट्विटर उपयोगकर्ता की डेटा संरचना इस तरह दिखती है:

    structure of twitter user data

    )


    अंडरस्कोर स्कोपिंग के साथ हम निम्नलिखित सम्मेलन का उपयोग करके यूआरएल तत्व में होस्टनाम से सही ट्विटर हैंडल का दावा कर सकते हैं:

    $ORIGIN Bombthrower.com.

    Stuntpope._twitter में TXT “स्टंटपोप”

    *._twitter में TXT “नकली”

    अपने आप से, ऐसा नहीं होता कुछ भी। कोई भी टर्मिनल विंडो खोलने वाला नहीं है और टाइप करें:

    “डिग-टी टीXT +शॉर्ट स्टंटपॉप._ट्विटर.बॉम्बथ्रोवर.कॉम”

    … यह पता लगाने के लिए कि क्या व्यक्ति आपको डीएम करते हुए, “आज आपका व्यापार कैसा चल रहा है?” वास्तव में मैं हूं, या स्टंटपोप के दिग्गजों में से एक ट्विटर पर मौजूद हैं। (मैं मजाक कर रहा हूं, उनके सही दिमाग में कोई भी मेरा प्रतिरूपण नहीं करेगा। लेकिन बहुत से फाइनविट प्रकाशकों के लिए, यह एक वास्तविक समस्या है।)

    लेकिन क्या हो सकता है अगर यह कन्वेंशन बन जाता है, क्या डेवलपर्स इन लुकअप को करने के लिए अपने ऐप्स में त्वरित और गंदे हुक बना सकते हैं। Twitter प्रोफ़ाइल के URL फ़ील्ड में। यदि वास्तविक उपयोगकर्ता के पास ऊपर उल्लिखित रिकॉर्ड हैं, तो नकली ट्विटर हैंडल को असली URL पर देखने की परंपरा वास्तविक याद नहीं आएगी _ट्विटर वास्तविक प्रोफ़ाइल के लिए TXT रिकॉर्ड, और वाइल्डकार्ड रिकॉर्ड को हिट करता है, जिससे बेमेल हो जाता है।


    हमने

    के माध्यम से एक अवधारणा का सबूत क्रोम एक्सटेंशन जारी किया है आसान डीएनएस Github, जो सिर्फ तीन मोड के साथ ऐसा करता है:

    A) कोई जानकारी नहीं दी गई;

    B) प्रोफ़ाइल दावा की गई जानकारी से मेल खाती है;

    C) प्रोफ़ाइल दावा की गई जानकारी से मेल नहीं खाती (यह नकली है)।

    यह सब और अधिक, कर सकते हैं एक सर्वव्यापी प्रोटोकॉल में बहुत ही सरल सम्मेलनों का उपयोग करके किया जा सकता है जो पहले से ही तैनात है।

    twitter proof of verification easy API use



    निष्कर्ष

    वॉलेट पते किसी प्रकार के नामकरण तंत्र की आवश्यकता के लिए खुद को उधार देते हैं। ऐसे कई उपयोग के मामले हैं जहां किसी पहचान से किसी पते को सुरक्षित रूप से दर्ज करने की आवश्यकता छद्म नाम या गुमनामी से अधिक होती है।

    इसके अलावा, मानव-पठनीय लेबल या पहचानकर्ताओं का उपयोग करने के लिए, हमें एक अमूर्त परत की आवश्यकता होती है जो लचीलापन और एक प्रारूप प्रदान करता है जिसे आसानी से पहचाना जा सकता है।

    अंत में, हम डीएनएस का उपयोग करके यह सब हासिल कर सकते हैं, जो पहले से ही इंटरनेट के तकनीकी बुनियादी ढांचे को रेखांकित करता है, पहले से ही एक विकेन्द्रीकृत संघ है और विकेंद्रीकृत परत 1 प्रोटोकॉल पर एंकरिंग करने का अपना तरीका। हम बिना किसी नए रिकॉर्ड प्रकार को जोड़े या मौजूदा विनिर्देशों में कोई प्रोटोकॉल जोड़े बिना ऐसा कर सकते हैं। व्यक्त की गई राय पूरी तरह से उनके अपने हैं और जरूरी नहीं कि वे बीटीसी इंक या बिटकॉइन पत्रिका.

    को प्रतिबिंबित करें।

    Back to top button
    %d bloggers like this: