नाही, ब्लॉकचेनवर विकेंद्रित ऍप्लिकेशन (dapp) लाँच केल्याने यशस्वी व्यवसाय होणार नाही. खरं तर, बहुतेक वापरकर्ते ऍप्लिकेशन ब्लॉकचेनवर चालतात की नाही याचा विचारही करत नाहीत - ते फक्त स्वस्त, जलद आणि सोपे उत्पादन निवडतात.

दुर्दैवाने, जरी ब्लॉकचेनची स्वतःची विशिष्ट वैशिष्ट्ये आणि फायदे आहेत, तरीही त्यावर चालणारे बहुतेक ऍप्लिकेशन्स त्यांच्या केंद्रीकृत प्रतिस्पर्ध्यांपेक्षा जास्त महाग, हळू आणि कमी अंतर्ज्ञानी आहेत.

ब्लॉकचेनवर बनवलेल्या अॅप्लिकेशन्सच्या व्हाईटपेपरमध्ये, तुम्हाला एक परिच्छेद सापडतो ज्यामध्ये असे म्हटले आहे: "ब्लॉकचेन महाग आहे आणि प्रति सेकंद आवश्यक संख्येने व्यवहारांना समर्थन देऊ शकत नाही. सुदैवाने, बरेच हुशार लोक ब्लॉकचेन स्केलिंगवर काम करत आहेत आणि आमचा ऍप्लिकेशन लाँच होईल तोपर्यंत ते स्केलेबल होईल.”

एका साध्या परिच्छेदात, dapp विकासक स्केलेबिलिटी समस्या आणि समस्यांचे पर्यायी उपाय यावर सखोल चर्चा सोडून देऊ शकतो. यामुळे बर्‍याचदा अकार्यक्षम आर्किटेक्चर होते जेथे ब्लॉकचेनवर चालणारे स्मार्ट कॉन्ट्रॅक्ट हे ऍप्लिकेशनचे बॅकएंड आणि गाभा म्हणून काम करतात.

तथापि, विकेंद्रित ऍप्लिकेशन आर्किटेक्चरसाठी अद्याप चाचणी न केलेले दृष्टिकोन आहेत जे ब्लॉकचेनवरील अवलंबित्व कमी करून अधिक चांगल्या स्केलेबिलिटीसाठी परवानगी देतात. उदाहरणार्थ, ब्लॉकस्टॅक अशा आर्किटेक्चरवर काम करत आहे जिथे बहुतेक ऍप्लिकेशन डेटा आणि लॉजिक ऑफ-चेन संग्रहित केले जाते.

चला प्रथम अधिक पारंपारिक दृष्टीकोन पाहू, जो अनुप्रयोग वापरकर्त्यांमधील थेट मध्यस्थ म्हणून ब्लॉकचेनचा वापर करतो आणि जो विशेषत: योग्य प्रमाणात होत नाही.

दृष्टीकोन #1: बॅकएंड म्हणून ब्लॉकचेन

गोष्टी अधिक स्पष्ट करण्यासाठी, हॉटेल उद्योगाचे उदाहरण घेऊ. हा एक मोठा उद्योग आहे ज्यात Booking.com सारखे मध्यस्थ, ते प्रचंड शुल्क आकारतात अतिथी आणि हॉटेल्स जोडण्यासाठी.

या दृष्टिकोनाचा वापर करून अशा मध्यस्थाचा पराभव करू इच्छित असलेल्या कोणत्याही परिस्थितीत, आम्ही इथरियमसारख्या ब्लॉकचेनवर स्मार्ट कॉन्ट्रॅक्टचा वापर करून त्याच्या व्यावसायिक तर्काची प्रतिकृती बनवण्याचा प्रयत्न करू.

"वर्ल्ड कॉम्प्युटर" वर चालणारे ओपन सोर्स स्मार्ट कॉन्ट्रॅक्ट्स मध्यस्थांकडून आकारले जाणारे शुल्क आणि कमिशन कमी करून, मध्यंतरी तृतीय पक्षाशिवाय व्यापाऱ्यांना ग्राहकांशी जोडू शकतात.

खाली दिलेल्या प्रतिमेत दाखवल्याप्रमाणे, हॉटेल्स ब्लॉकचेनवरील खोल्यांबद्दल माहिती, आठवड्याच्या दिवसात किंवा आठवड्याच्या शेवटी त्यांची उपलब्धता आणि किंमती आणि कदाचित इतर सर्व संबंधित माहितीसह खोल्यांचे वर्णन पोस्ट करण्यासाठी विकेंद्रित अनुप्रयोग वापरतात.

ज्याला रूम बुक करायची आहे तो हा ऍप्लिकेशन ब्लॉकचेनवर होस्ट केलेले हॉटेल आणि खोल्या शोधण्यासाठी वापरतो. एकदा वापरकर्त्याने खोली निवडल्यानंतर, हॉटेलला टोकनची आवश्यक रक्कम ठेव म्हणून पाठवून आरक्षण केले जाते. आणि प्रतिसादात, स्मार्ट कॉन्ट्रॅक्ट ब्लॉकचेनमधील माहिती अपडेट करते की नंबर आता उपलब्ध नाही.

या दृष्टिकोनासह स्केलेबिलिटी समस्येच्या दोन बाजू आहेत. प्रथम, प्रति सेकंद व्यवहारांची कमाल संख्या. दुसरे म्हणजे, ब्लॉकचेनवर किती डेटा संग्रहित केला जाऊ शकतो.

चला काही ढोबळ गणना करूया. Booking.com म्हणते की त्यांच्याकडे जवळपास 2 दशलक्ष हॉटेल्स नोंदणीकृत आहेत. समजा की सरासरी हॉटेलमध्ये 10 खोल्या आहेत आणि प्रत्येक खोल्या वर्षातून फक्त 20 वेळा बुक केल्या जातात - यामुळे आम्हाला प्रति सेकंद सरासरी 13 बुकिंग मिळतात.

ही संख्या दृष्टीकोनात ठेवण्यासाठी, हे लक्षात घेण्यासारखे आहे की इथरियम प्रति सेकंद अंदाजे 15 व्यवहारांवर प्रक्रिया करू शकते.

त्याच वेळी, हे लक्षात घेण्यासारखे आहे की आमच्या अनुप्रयोगात हॉटेलमधील व्यवहार देखील असतील - त्यांच्या खोल्यांची माहिती डाउनलोड करण्यासाठी आणि सतत अद्यतनित करण्यासाठी. हॉटेल्स खोलीच्या किमती वारंवार अपडेट करतात, कधी कधी अगदी दररोज, आणि प्रत्येक किंमत किंवा वर्णन बदलण्यासाठी ब्लॉकचेनवर व्यवहार करणे आवश्यक आहे.

येथे आकाराच्या समस्या देखील आहेत - इथरियम ब्लॉकचेनचे वजन नुकतेच 2TB मार्क पार केले आहे. या दृष्टिकोनासह अनुप्रयोग खरोखर लोकप्रिय झाल्यास, इथरियम नेटवर्क अत्यंत अस्थिर होईल.

अशी ब्लॉकचेन-आधारित प्रणाली त्याच्या निःपक्षपातीपणामुळे आणि केंद्रीकरणाच्या अभावामुळे बाहेरील लोकांना वगळू शकते, ब्लॉकचेन तंत्रज्ञानाचे मुख्य फायदे. परंतु ब्लॉकचेनमध्ये इतर वैशिष्ट्ये देखील आहेत - ती वितरीत केली जाते आणि पुन्हा लिहिली जात नाही, ही उत्कृष्ट वैशिष्ट्ये आहेत, परंतु आपल्याला त्यांच्यासाठी व्यवहारांच्या गती आणि कमिशनमध्ये पैसे द्यावे लागतील.

म्हणून, dapp विकासकांनी ब्लॉकचेन वापरणाऱ्या प्रत्येक वैशिष्ट्याला खरोखरच वितरण आणि गैर-लेखनक्षमतेची आवश्यकता आहे का हे काळजीपूर्वक मूल्यांकन करणे आवश्यक आहे.

उदाहरणार्थ: प्रत्येक हॉटेलचा डेटा जगभरातील शेकडो मशीनमध्ये वितरित करून आणि तो कायमस्वरूपी संग्रहित करण्याचा काय फायदा आहे? हे खरोखर महत्वाचे आहे की खोलीचे दर आणि उपलब्धता यावरील ऐतिहासिक डेटा नेहमी ब्लॉकचेनमध्ये समाविष्ट केला जातो? कदाचित नाही.

जर आम्ही असे प्रश्न विचारण्यास सुरुवात केली, तर आम्हाला आमच्या सर्व फंक्शन्ससाठी सर्व महागड्या ब्लॉकचेन वैशिष्ट्यांची आवश्यकता नाही हे लक्षात येईल. तर, पर्याय काय आहे?

दृष्टीकोन #2: ब्लॉकस्टॅक प्रेरित आर्किटेक्चर

जरी मुख्य भर ब्लॉकस्टॅक ज्या अनुप्रयोगांमध्ये वापरकर्ते त्यांच्या डेटाचे मालक आहेत (उदाहरणार्थ, जसे एअरटेक्स्ट, BentenSound, इमेज ऑप्टिमायझर किंवा ग्रेफाइट), ब्लॉकस्टॅकमध्ये ब्लॉकचेन हलकेच वापरण्याचे तत्वज्ञान आहे-फक्त जेव्हा अगदी आवश्यक असेल. त्यांचा मुख्य युक्तिवाद असा आहे की ब्लॉकचेन धीमे आणि महाग आहे, आणि म्हणूनच ते फक्त एकल किंवा क्वचित व्यवहारांसाठी वापरले जावे. अनुप्रयोगांसह उर्वरित परस्परसंवाद पीअर-टू-पीअरद्वारे व्हायला हवा, म्हणजे. विकेंद्रित ऍप्लिकेशन्सच्या वापरकर्त्यांनी ब्लॉकचेन ऐवजी थेट एकमेकांशी डेटा शेअर केला पाहिजे. शेवटी, BitTorrent, ईमेल आणि Tor सारखे सर्वात जुने आणि सर्वात यशस्वी विकेंद्रित ऍप्लिकेशन्स ब्लॉकचेनच्या संकल्पनेपूर्वीच तयार केले गेले होते.

डावीकडे: पहिला दृष्टिकोन, ज्यामध्ये वापरकर्ते ब्लॉकचेनद्वारे संवाद साधतात. उजवीकडे: वापरकर्ते एकमेकांशी थेट संवाद साधतात, आणि ब्लॉकचेनचा वापर फक्त ओळख आणि इतर गोष्टींसाठी केला जातो.

चला हॉटेल बुकिंगच्या उदाहरणावर परत जाऊ या. हॉटेल्सशी अतिथींना जोडण्यासाठी आम्हाला निष्पक्ष, स्वतंत्र आणि खुला प्रोटोकॉल हवा आहे. दुसऱ्या शब्दांत, आम्हाला केंद्रीकृत मध्यस्थ काढून टाकायचे आहे. आम्हाला गरज नाही, उदाहरणार्थ, खोलीच्या किमती एका सामान्य वितरीत लेजरमध्ये सतत साठवण्याची.

आम्ही फक्त अतिथी आणि हॉटेल्सना ब्लॉकचेन द्वारे थेट संवाद साधण्याची परवानगी का देत नाही? हॉटेल्स त्यांच्या किंमती, खोलीची उपलब्धता आणि इतर कोणतीही माहिती कोठेतरी संग्रहित करू शकतात जिथे ती प्रत्येकासाठी प्रवेशयोग्य असेल - उदाहरणार्थ, IPFS, Amazon S3 किंवा अगदी त्यांचे स्वतःचे स्थानिक सर्व्हर. ब्लॉकस्टॅकच्या विकेंद्रित स्टोरेज सिस्टमला नेमके हेच म्हणतात गाया. हे वापरकर्त्यांना त्यांचा डेटा कोठे संग्रहित करायचा आहे ते निवडण्याची आणि कॉल केलेल्या दृष्टिकोनाद्वारे कोण त्यात प्रवेश करू शकतो हे नियंत्रित करण्यास अनुमती देते बहु-वापरकर्ता संचयन.

विश्वास प्रस्थापित करण्यासाठी, हॉटेलचा सर्व डेटा क्रिप्टोग्राफिक पद्धतीने हॉटेलद्वारे स्वाक्षरी केलेला असतो. हा डेटा कोठे संग्रहित केला आहे याची पर्वा न करता, ब्लॉकचेनवर संग्रहित हॉटेलच्या ओळखीशी संबंधित सार्वजनिक की वापरून त्याची अखंडता सत्यापित केली जाऊ शकते.

ब्लॉकस्टॅकच्या बाबतीत, फक्त तुमची ओळख माहिती ब्लॉकचेनवर संग्रहित केली जाते. प्रत्येक वापरकर्त्याचा डेटा कसा मिळवायचा याची माहिती झोन ​​फाइल्समध्ये संग्रहित केली जाते आणि नोड्स वापरून पीअर-टू-पीअर नेटवर्कद्वारे वितरित केली जाते. आणि पुन्हा एकदा, तुम्हाला नोड्स देत असलेल्या डेटावर विश्वास ठेवण्याची गरज नाही, कारण तुम्ही ब्लॉकचेन आणि इतर वापरकर्त्यांमध्ये साठवलेल्या हॅशशी तुलना करून त्याची सत्यता सत्यापित करू शकता.

सिस्टीमच्या सरलीकृत आवृत्तीमध्ये, अतिथी हॉटेल्स शोधण्यासाठी आणि त्यांच्या खोल्यांबद्दल माहिती मिळवण्यासाठी ब्लॉकस्टॅक पीअर-टू-पीअर नेटवर्कचा वापर करतील. आणि आपण प्राप्त केलेल्या सर्व डेटाची सत्यता आणि अखंडता सार्वजनिक की आणि संग्रहित हॅश वापरून सत्यापित केली जाऊ शकते आभासी सर्किट ब्लॉकस्टॅक.

हे आर्किटेक्चर पहिल्या दृष्टिकोनापेक्षा अधिक जटिल आहे आणि अधिक व्यापक पायाभूत सुविधांची आवश्यकता आहे. खरं तर, येथेच ब्लॉकस्टॅक येतो, जे अशा विकेंद्रित प्रणाली तयार करण्यासाठी सर्व आवश्यक घटक प्रदान करते.

या आर्किटेक्चरसह, आम्ही फक्त ब्लॉकचेनवर डेटा संग्रहित करतो ज्याला खरोखर वितरित करणे आवश्यक आहे आणि ओव्हरराईट केले जात नाही. ब्लॉकस्टॅकच्या बाबतीत, तुम्हाला फक्त नोंदणी करण्यासाठी आणि तुमचा डेटा कुठे संग्रहित केला जावा हे सूचित करण्यासाठी ब्लॉकचेनवर व्यवहार करणे आवश्यक आहे. तुम्हाला यापैकी कोणतीही माहिती बदलायची असल्यास तुम्हाला अधिक व्यवहार करावे लागतील, परंतु ही पुनरावृत्ती होणारी घटना नाही.

शिवाय, ऍप्लिकेशन लॉजिक, पहिल्या पध्दतीच्या विरूद्ध, क्लायंटच्या बाजूने चालते आणि स्मार्ट कॉन्ट्रॅक्टवर नाही. हे विकसकाला हे तर्कशास्त्र खर्चिक किंवा कधी कधी अशक्य स्मार्ट कॉन्ट्रॅक्ट अपडेट्सशिवाय बदलू देते. आणि ऍप्लिकेशन डेटा आणि लॉजिक ऑफ-चेन ठेवून, विकेंद्रित ऍप्लिकेशन्स पारंपारिक केंद्रीकृत सिस्टमची कार्यक्षमता आणि स्केलेबिलिटी पातळी प्राप्त करू शकतात.

निष्कर्ष

ब्लॉकस्टॅकवर चालणारे ऍप्लिकेशन्स पारंपरिक ब्लॉकचेन ऍप्लिकेशन्सपेक्षा खूप चांगले स्केल करू शकतात, परंतु हे स्वतःच्या समस्या आणि अनुत्तरीत प्रश्नांसह एक तरुण दृष्टीकोन आहे.

उदाहरणार्थ, जर विकेंद्रित ऍप्लिकेशन स्मार्ट कॉन्ट्रॅक्टवर चालत नसेल, तर यामुळे युटिलिटी टोकनची गरज कमी होते. विकेंद्रित ऍप्लिकेशन्ससाठी (ब्लॉकस्टॅकसह) आयसीओ हे मुख्य स्त्रोत आहेत हे लक्षात घेऊन व्यवसायांसाठी यामुळे समस्या निर्माण होऊ शकतात.

येथेही तांत्रिक अडचणी आहेत. उदाहरणार्थ, स्मार्ट कॉन्ट्रॅक्टमध्ये हॉटेल बुकिंग फंक्शन लागू करणे तुलनेने सोपे आहे, जेथे परमाणु ऑपरेशनमध्ये, टोकनच्या बदल्यात खोलीचे आरक्षण केले जाते. आणि स्मार्ट कॉन्ट्रॅक्टशिवाय ब्लॉकस्टॅक ऍप्लिकेशनमध्ये बुकिंग कसे कार्य करेल हे स्पष्ट नाही.

लाखो वापरकर्त्यांच्या संभाव्यतेसह जागतिक बाजारपेठांना लक्ष्य करणारे अॅप्स यशस्वी होण्यासाठी खूप चांगले स्केल करणे आवश्यक आहे. नजीकच्या भविष्यात स्केलेबिलिटीचा हा स्तर साध्य करण्यासाठी केवळ ब्लॉकचेनवर अवलंबून राहणे ही चूक आहे. Booking.com सारख्या मोठ्या केंद्रीकृत बाजारातील खेळाडूंशी स्पर्धा करण्यास सक्षम होण्यासाठी, विकेंद्रित ऍप्लिकेशन डेव्हलपर्सनी त्यांचे ऍप्लिकेशन डिझाइन करण्यासाठी पर्यायी पध्दतींचा विचार केला पाहिजे, जसे की ब्लॉकस्टॅकने ऑफर केलेले.

स्त्रोत: www.habr.com