विचार नेता
सुरक्षा टोकन प्रोटोकॉल में इंटरऑपरेबिलिटी की आवश्यकता – थॉट लीडर्स
टोकन का संक्षिप्त इतिहास
बिटकॉइन ने पहली बार ब्लॉकचेन तकनीक को दुनिया में प्रस्तुत किए हुए 10 से अधिक वर्ष हो चुके हैं। इस दौरान, वितरित लेज़र के संभावित उपयोग मामलों की सूची तेज़ी से विस्तारित हुई है, डिजिटल मुद्राओं से लेकर आपूर्ति श्रृंखलाओं और पहचान प्रबंधन तक। हालांकि, इनके मूल में कई उपयोग मामलों की संरचना समान है: वे उपयोगकर्ताओं को पीयर‑टू‑पीयर आधार पर डिजिटल संपत्तियों को धारण और स्थानांतरित करने की अनुमति देते हैं। सरल शब्दों में, अब हम केंद्रीय विश्वसनीय प्राधिकारी की आवश्यकता के बिना डिजिटल संपत्तियों का व्यापार और ट्रैकिंग कर सकते हैं।
इस क्षेत्र के विकास ने स्वाभाविक रूप से “टोकन” के आविष्कार को जन्म दिया — ब्लॉकचेन पर डिजिटल संपत्तियां जो व्यक्तिगत रूप से स्वामित्व में रखी जा सकती हैं और एक व्यक्ति से दूसरे व्यक्ति को स्थानांतरित की जा सकती हैं। टोकन दो मुख्य श्रेणियों में विभाजित होते हैं: वे जो मूल रूप से डिजिटल संपत्ति का प्रतिनिधित्व करते हैं, और वे जो वास्तविक दुनिया की अंतर्निहित संपत्ति का प्रतिनिधित्व करते हैं। इस नई अवधारणा का उपयोग करके, केवल एथेरियम पर ही सैकड़ों हजारों विभिन्न टोकन बनाए जा चुके हैं, जिनका संयुक्त बाजार पूंजी लेखन के समय $15 बिलियन से अधिक है।
टोकन का एक सबसे आशाजनक अनुप्रयोग वास्तविक दुनिया के सिक्योरिटीज़ को ऑन‑चेन प्रतिनिधित्व करना है, जिससे पारंपरिक रूप से अलिक्विड संपत्तियों जैसे वाणिज्यिक रियल एस्टेट को अंशिक रूप में विभाजित करके पीयर‑टू‑पीयर स्थानांतरित किया जा सकता है। इस प्रक्रिया को “टोकनाइज़ेशन” कहा जाता है, और यह पूंजी बाजारों में मौजूद कई दर्द बिंदुओं को कम करने की क्षमता के कारण पारम्परिक संस्थानों और नई स्टार्ट‑अप्स दोनों का ध्यान आकर्षित कर चुकी है।
नियामक अनुपालन
जबकि ब्लॉकचेन तकनीकी रूप से स्वामित्व स्थानांतरण को आसान बना सकता है, सुरक्षा टोकन अभी भी पारंपरिक सिक्योरिटीज़ की समान कानूनों और नियमों के अधीन होते हैं। इसलिए सुरक्षा टोकनों का नियामक अनुपालन सुनिश्चित करना किसी भी संभावित टोकनाइज़ेशन के लिए अत्यंत महत्वपूर्ण है, और अब तक यह अपनाने में बाधा रहा है। नीचे के चार्ट में दिखाए अनुसार, नियामक अनिश्चितता को व्यापक रूप से ब्लॉकचेन अपनाने की सबसे बड़ी बाधा माना जाता है।
ब्लॉकचेन क्षेत्र में कई परियोजनाएँ उभरी हैं, प्रत्येक ने एक प्रोटोकॉल डिजाइन किया है जो सुरक्षा टोकनों के नियमन, ट्रेडिंग और प्रबंधन को सरल और मानकीकृत करने का प्रयास करता है। केवल एथेरियम को देखें तो इस समस्या को हल करने वाले मानकों को प्रकाशित करने वाली परियोजनाओं में Securitize, Harbor, Polymath और अन्य शामिल हैं। हालांकि अंततः, इन प्रोटोकॉल के वर्तमान डिजाइन में बदलाव के बिना, निवेशकों और एक्सचेंजों को टोकनाइज़्ड सिक्योरिटीज़ खरीदने‑बेचने में महत्वपूर्ण घर्षण का सामना करना पड़ेगा। इसका कारण क्या है? इंटरऑपरेबिलिटी।
इंटरऑपरेबिलिटी अत्यावश्यक है
इंटरऑपरेबिलिटी टोकनाइज़ेशन का सबसे महत्वपूर्ण लाभों में से एक है। यह पूंजी बाजार अनुप्रयोगों और उत्पादों के पूरे इकोसिस्टम को एक-दूसरे के साथ एकीकृत करने की अनुमति देता है क्योंकि वे सामान्य सॉफ़्टवेयर मानकों को साझा करते हैं। हालांकि, एप्लिकेशन और उत्पाद स्तर पर इंटरऑपरेबिलिटी सक्षम करने के लिए, यह सबसे निचले स्तर पर टोकनों से शुरू होना चाहिए। सुरक्षा टोकन क्षेत्र में, इंटरऑपरेबिलिटी दो प्रमुख पक्षों के लिए आवश्यक है: एक्सचेंज और निवेशक।
एक एक्सचेंज के रूप में, आप चाहते हैं कि आप उन सभी सुरक्षा टोकनों की खरीद के लिए निवेशकों को अधिकृत कर सकें, जिनके लिए वे योग्य हैं — चाहे टोकन किस कंपनी ने बनाया हो। इसका अर्थ है प्रत्येक सुरक्षा टोकन के साथ एक विशेष एकीकरण न होना, बल्कि सभी सुरक्षा टोकनों के लिए समान और सामान्य एकीकरण होना।
एक निवेशक के रूप में, आप चाहते हैं कि ऑनबोर्डिंग प्रक्रिया यथासंभव सरल और बिना घर्षण के हो। वर्तमान में जब एक निवेशक कई स्थानों से शेयर खरीदना चाहता है, तो उन्हें अपने व्यक्तिगत जानकारी को बार‑बार “नो योर कस्टमर” (KYC) प्रक्रिया में प्रदान करना पड़ता है। ब्लॉकचेन इस प्रक्रिया को बदल सकता है, क्योंकि यह जानकारी को अपरिवर्तनीय रूप से ऑन‑चेन संग्रहीत कर सकता है, जिसे सभी सुरक्षा टोकन संदर्भित कर सकते हैं। इसका मतलब होगा कि प्रत्येक नई टोकन खरीदते समय वही व्यक्तिगत जानकारी दोहराने की आवश्यकता नहीं होगी; केवल प्रारंभिक पंजीकरण के बाद अतिरिक्त या अपडेटेड जानकारी ही आवश्यक होगी। हालांकि, यह प्रक्रिया तभी संभव होगी जब सुरक्षा टोकनों के बीच इंटरऑपरेबिलिटी को उन मानकों में डिज़ाइन किया गया हो जो प्रणाली को नियंत्रित करते हैं।
प्रोटोकॉल
एथेरियम के प्रमुख तीन सुरक्षा टोकन प्रोटोकॉल Securitize, Harbor और Polymath द्वारा प्रकाशित किए गए थे। इन तीनों प्रोटोकॉल सभी एथेरियम के ERC‑20 टोकन मानक पर निर्मित हैं, जिसे वे फिर सुरक्षा टोकन के ट्रेडिंग में अनुपालन लागू करने के लिए विस्तारित करते हैं। यह प्रत्येक ट्रेड की वैधता को उस समय जांचने के लिए एक द्वितीय अनुबंध को क्वेरी करके प्राप्त किया जाता है।
प्रोटोकॉल में नाम अलग-अलग हो सकते हैं, लेकिन द्वितीय अनुबंध का उपयोग सभी तीनों में समान है, जिसका परिणाम वही है: गैर‑अनुपालन ट्रेड को रोकना। यह द्वितीय ‘रेगुलेटर’ अनुबंध उपयोगकर्ताओं के KYC और मान्यता जानकारी को ऑफ‑चेन सेवाओं द्वारा अद्यतन रखा जाता है, जो इसे करने के लिए अधिकृत होती हैं — उदाहरण के लिए एक एक्सचेंज या टोकन जारीकर्ता।
हालांकि ये तीन घटक ऐसा लग सकता है कि सुरक्षा टोकन को नियमन करने के लिए सभी आवश्यक चीजें हैं (और सबसे सरल रूप में, वे हैं), वास्तव में घटकों के प्रोग्रामिंग तरीके ही इंटरऑपरेबिलिटी को निर्धारित करते हैं। दुर्भाग्यवश, प्रोटोकॉल दो प्रमुख क्षेत्रों में इंटरऑपरेबिलिटी की कमी रखते हैं, जो इस तकनीक को अपनाने में घर्षण और धीमी गति का कारण बनेंगे:
- अधिकृत पक्ष उपयोगकर्ताओं की ऑन‑चेन जानकारी को कैसे अपडेट करते हैं?
Harbor
Harbor अपने व्हाइटपेपर में घोषणा करता है कि वह वर्तमान में उपयोगकर्ता जानकारी को ऑन‑चेन अपडेट करने के लिए एकमात्र अधिकृत पक्ष होगा। इस भूमिका का केंद्रीकरण यह意味 देता है कि एक्सचेंज रेगुलेटर द्वारा संदर्भित किसी भी डेटा को अपडेट नहीं करेंगे। परिणामस्वरूप वे टोकन के नए प्राप्तकर्ताओं को अनुमोदित नहीं कर पाएंगे, जिससे टोकन को Harbor प्लेटफ़ॉर्म के बाहर आसानी से ट्रेड करना कठिन हो जाएगा।
Securitize
Securitize ने पहले ही एक प्रणाली लागू कर ली है जिसमें कई पक्षों को अधिकृत किया जा सकता है, जिसका अर्थ है कि निवेशक अपनी अनुपालन जानकारी कई स्थानों पर पंजीकृत कर सकते हैं और उन्हें स्वयं Securitize के माध्यम से नहीं जाना पड़ता। ऑन‑चेन डेटा तब सीधे अधिकृत पक्ष द्वारा अपडेट किया जाता है, और इसे सभी Securitize टोकनों द्वारा देखा जा सकता है। इसके अतिरिक्त, निवेशकों को कई बार जानकारी प्रदान करने से बचाने के लिए, Securitize ने एक API डिज़ाइन किया है जो अधिकृत पक्षों को ऑफ‑चेन संग्रहीत निवेशकों की निजी जानकारी तक पहुंचने की अनुमति देता है, जिससे वे आसानी से निर्धारित कर सकते हैं कि कोई व्यक्ति अनुपालन में है या अतिरिक्त जानकारी की आवश्यकता है।
Polymath
Polymath के पास POLY नामक एक मूल डिजिटल उपयोगिता टोकन है, जो उनके प्लेटफ़ॉर्म पर विभिन्न कार्यों को करने के लिए आवश्यक है, जिसमें अधिकृत पक्ष को आपके ऑन‑चेन डेटा को अपडेट करने के लिए भी शामिल है। किसी व्यक्ति को स्वयं KYC करने के लिए, उन्हें पहले POLY टोकन खरीदने पड़ते हैं, जिसके पास फिएट‑से‑POLY का तरल बाजार नहीं है। इसके बजाय व्यक्ति को फिएट का उपयोग करके एथेरियम के “ईथर” (ETH) जैसी अन्य क्रिप्टोकरेंसी खरीदनी पड़ती है, और फिर इसे POLY में बदलना पड़ता है। इन टोकनों को फिर Polymath के KYC मार्केटप्लेस पर KYC प्रदाता को बोली लगाने के लिए उपयोग किया जा सकता है। यदि KYC प्रदाता प्रस्ताव को स्वीकृत करता है, तो उन्हें व्यक्ति के लिए KYC जांच करने के लिए POLY टोकन में भुगतान किया जाता है। यह प्रक्रिया स्पष्ट रूप से Polymath प्लेटफ़ॉर्म पर एक महत्वपूर्ण ऑनबोर्डिंग घर्षण है, और प्रक्रिया को आवश्यक से अधिक जटिल बनाती है।
- उपयोगकर्ताओं की इस जानकारी को फिर ऑन‑चेन कैसे संग्रहीत और एक्सेस किया जाता है?
Harbor
GitHub पर व्हाइटपेपर और स्मार्ट कॉन्ट्रैक्ट्स को देख कर, तकनीकी रूप से संभव है कि Harbor के कई टोकन एक सामान्य रेगुलेटर अनुबंध और एक सामान्य उपयोगकर्ता डेटा स्रोत साझा करें, लेकिन विभिन्न टोकनों के नियमन में अंतर के कारण यह संभावना कम है। एथेरियम पर लाइव Harbor टोकनों की कमी ने यह स्पष्ट नहीं किया है कि यह उनका इरादा है या प्रत्येक टोकन को अपना स्वयं का रेगुलेटर के साथ डिप्लॉय किया जाएगा।
Securitize
Securitize का प्रोटोकॉल इस प्रकार डिज़ाइन किया गया है कि उनका रेगुलेटर अनुबंध एक तीसरे स्मार्ट कॉन्ट्रैक्ट को क्वेरी करता है जो उपयोगकर्ता जानकारी संग्रहीत करता है। यह प्रत्येक टोकन को अपने व्यक्तिगत रेगुलेटर में अद्वितीय नियम एन्कोड करने की अनुमति देता है, जबकि तीसरे कॉन्ट्रैक्ट में एक सामान्य उपयोगकर्ता डेटा स्रोत साझा करता है, जिसका अर्थ है कि जब कोई उपयोगकर्ता एक Securitize टोकन के लिए KYC करता है, तो उसकी जानकारी संग्रहीत हो जाती है और भविष्य के टोकन खरीदने के लिए तैयार रहती है।
Polymath
उनके व्हाइटपेपर में स्पष्ट रूप से नहीं बताया गया है कि Polymath के पास ऑन‑चेन संग्रहीत एक केंद्रीय अनुपालन डेटा स्रोत है जिससे प्रत्येक रेगुलेटर इंटरैक्ट करता है, या टोकनों के पास अपना स्थानीय सूचना स्रोत है। हालांकि, Polymath के नमूना कॉन्ट्रैक्ट्स के आधार पर, ऐसा प्रतीत होता है कि प्रत्येक टोकन एक स्थानीय सूचना स्रोत का उपयोग करता है, जो विभिन्न टोकनों के बीच साझा नहीं किया जाता। जबकि इससे कुछ लाभ हो सकते हैं, यह सेटअप डेटा की पुनरावृत्ति और असंगतियों के जोखिम को बढ़ाता है।
निम्नलिखित उदाहरण पर विचार करें: बॉब ने दो Polymath सुरक्षा टोकनों, ABC और DEF, में रुचि व्यक्त की है, और प्रत्येक के लिए निवेशक के रूप में अनुमोदित किया गया है। यह जानकारी प्रत्येक टोकन के रेगुलेटर अनुबंध को भेजी जाती है। एक महीने बाद, बॉब आगे DEF टोकन खरीदने का प्रयास करता है, लेकिन पता चलता है कि वह अब मान्य नहीं है। यह जानकारी DEF के रेगुलेटर को भेजी जाती है ताकि बॉब की निवेशक स्थिति को गैर‑मान्य में अपडेट किया जा सके। अब, ऑन‑चेन पर विरोधाभासी जानकारी मौजूद है: ABC मानता है कि बॉब एक सत्यापित निवेशक है, जबकि DEF असहमत है। यह स्पष्ट है कि एक केंद्रीय सूचना स्रोत होने से ऐसी विसंगतियों से बचा जा सकता है।
प्रोटोकॉल की इंटरऑपरेबिलिटी
जैसा कि पहले चर्चा की गई, सुरक्षा टोकनों के जारी करने और एक्सचेंज में दो मुख्य पक्ष शामिल हैं, जिनके लिए इंटरऑपरेबिलिटी अत्यधिक महत्वपूर्ण होगी: एक्सचेंज और निवेशक। दोनों पक्ष विभिन्न सुरक्षा टोकनों के साथ इंटरैक्ट करते समय एक सुगम अनुभव चाहते हैं। इसलिए, यदि प्रोटोकॉल को जैसा है वैसा ही उपयोग किया जाए, तो आइए देखें कि एक्सचेंज और उपयोगकर्ताओं पर इसका क्या प्रभाव पड़ेगा।
Exchanges
एक एक्सचेंज के रूप में, ट्रांसफ़र के उद्देश्य से इन प्रोटोकॉल को एकीकृत करना आसान है: सभी टोकन ERC‑20 टोकन मानक का उपयोग करते हैं, जो ट्रांसफ़र, अनुमोदन और बैलेंस जाँच को कॉल करने के लिए एक समान इंटरफ़ेस प्रदान करता है। हालांकि, प्रत्येक प्रोटोकॉल के अनुपालन पहलू के साथ आगे का एकीकरण काफी जटिल हो जाता है। आपको याद होगा कि वर्तमान में एक भरोसेमंद पक्ष के लिए Harbor प्रोटोकॉल पर अधिकृत होना संभव नहीं है — उन्हें उपयोगकर्ताओं को Harbor पर स्वयं KYC करने के लिए निर्देशित करना होगा। फिर Securitize प्रोटोकॉल के साथ एकीकृत करने के लिए, भरोसेमंद पक्ष को Securitize द्वारा अधिकृत होना चाहिए, जिससे उन्हें ऑफ‑चेन API के माध्यम से निवेशक KYC डेटा तक पहुंच और ऑन‑चेन डेटा स्टोर में संग्रहीत जानकारी को अपडेट करने की अनुमति मिलेगी।
Polymath प्रोटोकॉल के साथ एकीकरण संभवतः सबसे जटिल है। भरोसेमंद पक्ष को Polymath के KYC मार्केटप्लेस पर स्वयं को KYC प्रदाता के रूप में पंजीकृत करना होगा और KYC सेवाएँ प्रदान करने के बदले POLY टोकन में बोली प्राप्त करने के लिए सेट अप करना होगा। निवेशकों को KYC सेवाएँ प्रदान करते समय, भरोसेमंद पक्ष को यह सुनिश्चित करने के लिए एक व्यवस्था करनी होगी कि प्रत्येक सुरक्षा के रेगुलेटर में उपयोगकर्ता के बारे में संग्रहीत दोहराव वाली ऑन‑चेन डेटा असंगत न हो।
केवल इंटरफ़ेस के विभिन्न प्रकार नहीं हैं जिन्हें भरोसेमंद पक्ष को एकीकृत करना पड़ता है, बल्कि प्रत्येक प्रोटोकॉल में एक्सचेंज को त्रुटि रिपोर्टिंग प्रदान करने का अलग तरीका भी है। एक इंटरफ़ेस बनाते समय यह महत्वपूर्ण है कि उत्पन्न होने वाली किसी भी त्रुटि को उपयोगकर्ताओं के समझने योग्य रूप में अनुवादित किया जा सके। उदाहरण के लिए, यदि कोई उपयोगकर्ता टोकन नहीं खरीद पाता है, तो इसके कई कारण हो सकते हैं: सुरक्षा में अभी तक पूर्ण नहीं हुई होल्डिंग अवधि हो सकती है, या अधिकतम अनुमत धारकों की संख्या पर प्रतिबंध हो सकता है। इन संदेशों को उपयोगकर्ताओं तक पहुँचाने के लिए, एक्सचेंज को प्रत्येक प्रोटोकॉल के लिए अलग त्रुटि रिपोर्टिंग विधि के साथ एकीकृत होना पड़ेगा।
Investors
प्रोटोकॉल में वर्तमान में निवेशकों के ऑनबोर्डिंग के विभिन्न तरीकों के कारण, निवेशकों को विभिन्न प्लेटफ़ॉर्म पर कई बार व्यक्तिगत जानकारी प्रदान करनी पड़ सकती है और विभिन्न तरीकों से। यह इसलिए है क्योंकि Harbor ने किसी अन्य पक्ष को अधिकृत नहीं किया है, और Polymath निवेशकों को POLY टोकन का उपयोग करके KYC प्रक्रियाओं के लिए बोली लगाने की आवश्यकता रखता है। इन अनुपालन विधियों के लागू होने से उत्पन्न घर्षण निवेशकों को उन सिक्योरिटीज़ को खरीदने से अनिच्छुक या असमर्थ बना सकता है, जिन्हें वे अन्यथा खरीदते।
निवेशकों पर इस प्रोटोकॉल‑जनित घर्षण का पैमाना कुछ हद तक उन तरीकों से कम हो सकता है जिनसे एक्सचेंज प्रत्येक प्रोटोकॉल को एकीकृत करते हैं। उदाहरण के लिए, यदि कोई निवेशक Polymath टोकन खरीदने के लिए एक्सचेंज पर KYC करता है, तो वह एक्सचेंज, यदि अधिकृत हो, तो एक ही समय में Securitize के डेटा स्टोरेज को अपडेट करने का चयन कर सकता है। इसका मतलब होगा कि निवेशक की जानकारी भविष्य में आवश्यकता पड़ने पर ऑन‑चेन उपलब्ध होगी। हालांकि, यदि वर्तमान प्रोटोकॉल डिज़ाइन में कोई बदलाव नहीं किया जाता, तो सिक्योरिटीज़ को पंजीकृत करने और खरीदने की प्रक्रिया अभी भी कठिन बनी रहेगी।
Solutions
इस समस्या का समाधान जटिल होने की आवश्यकता नहीं है। वास्तव में, एथेरियम पर पहले से लाइव टोकनों को बदले बिना कुछ समाधान पेश करना संभव है। एक आदर्श समाधान जो एक्सचेंज और निवेशकों दोनों के लिए न्यूनतम घर्षण उत्पन्न करता है, और कई विभिन्न अनुपालन डेटा स्रोतों के कारण डेटा असंगतियों को रोकता है, वह Securitize के केंद्रीकृत ऑन‑चेन डेटा स्टोर के समान होगा; हालांकि, ऐसे सेट‑अप को उद्योग‑व्यापी स्तर पर अपनाया जाना चाहिए।
ऑन‑चेन पर एक केंद्रीय सूचना स्रोत होने से डेटा असंगतियों का जोखिम समाप्त हो जाता है, और निवेशक केवल एक ही अनुपालन सत्यापन के माध्यम से विभिन्न सिक्योरिटीज़ खरीद सकते हैं। यह केंद्रीय अनुबंध सभी सुरक्षा टोकनों के लिए यह सत्यापित करेगा कि ट्रांसफ़र अनुपालन में था, और ट्रांसफ़र जारी रहेगा या रिवर्ट हो जाएगा। सभी अधिकृत एक्सचेंजों के लिए उपलब्ध ऑफ‑चेन API का अर्थ है कि निवेशक अनुपालन जानकारी को एक्सचेंजों तक संप्रेषित किया जा सकता है और निवेशकों को डेटा प्रदान करने की संख्या कम हो जाती है। ये पहलू मिलकर एक्सचेंजों द्वारा आवश्यक एकीकरण कार्य की मात्रा को भी बहुत हद तक घटा देते हैं।
ऐसे नए सिस्टम का परिचय स्पष्ट रूप से कुछ जटिलताएँ लाता है, और कई मुद्दों को अभी भी सुलझाना होगा। उदाहरण के लिए, प्रत्येक एक्सचेंज के अधिकृत होने के डिजाइन में: यह निर्णय कौन लेगा कि किसी एक्सचेंज को भरोसेमंद माना जाए? एक ऐसा सिस्टम डिजाइन करने में समय लगना चाहिए जो सर्वसम्मति प्राप्त करने की अनुमति दे।
Conclusion
सिक्योरिटीज़ का टोकनाइज़ेशन अभी भी विकास और अपनाने के शुरुआती चरण में है, जिसका एक हिस्सा नियामक अनुपालन की जटिलताओं के कारण है। जबकि प्रोटोकॉल का प्रकाशन कई नियमों के अनुपालन को सरल बनाता है, क्योंकि यह प्रत्येक ट्रांसफ़र के निष्पादन में उन्हें लागू करने की अनुमति देता है, फिर भी इस प्रक्रिया को सहज बनाने के लिए अभी बहुत काम शेष है। जब तक प्रोटोकॉल इस बात पर सहमत नहीं होते कि निवेशक जानकारी को ऑन‑चेन और ऑफ‑चेन दोनों में कैसे संग्रहीत और अपडेट किया जाए, तब तक सभी पक्षों के पंजीकरण और निवेश प्रक्रियाओं में महत्वपूर्ण घर्षण बना रहेगा।
