स्मार्ट कॉन्ट्रैक्ट शोडाउन: हाइपरल्ड फैब्रिक बनाम मल्टीचैन बनाम एथेरेम बनाम कॉर्डा

ब्लॉकचेन पर कोड डालने का एक से अधिक तरीका है

ब्लॉकचेन के बारे में ज्यादातर चर्चाओं में, "स्मार्ट कॉन्ट्रैक्ट्स" की धारणा को सामने आने में देर नहीं लगती। एक लोकप्रिय मध्यस्थ की आवश्यकता के बिना, लोकप्रिय कल्पना में, स्मार्ट अनुबंध इंटरपार्टी इंटरैक्शन के निष्पादन को स्वचालित करते हैं। शब्दों के बजाय कोड में कानूनी संबंधों को व्यक्त करके, वे लेन-देन को सीधे और बिना त्रुटि के सक्षम करने का वादा करते हैं, चाहे जानबूझकर या नहीं।

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

इस लेख में, मेरा लक्ष्य स्मार्ट कॉन्ट्रैक्ट दृष्टिकोण और उनके द्वारा प्रतिनिधित्व किए जाने वाले व्यापार-बंदों के बीच कुछ प्रमुख अंतरों की जांच करना है। मैं चार लोकप्रिय एंटरप्राइज़ ब्लॉकचेन प्लेटफार्मों को देखकर ऐसा करूँगा जो कि अनुकूलित ऑन-चेन कोड के कुछ रूप का समर्थन करते हैं। सबसे पहले, आईबीएम हाइपरलेगर फैब्रिक, जो अपने अनुबंधों को "चैंकोड" कहता है। दूसरा, हमारा मल्टीचैन प्लेटफॉर्म, जो परिचय देता है स्मार्ट फिल्टर संस्करण 2.0 में। तीसरा, Ethereum (और इसकी अनुमति दी गई कोरम और बिल स्पिन-ऑफ), जिसने "स्मार्ट अनुबंध" नाम को लोकप्रिय बनाया। और अंत में, R3 कॉर्डा, जो अपने लेनदेन में "अनुबंध" का संदर्भ देता है। सभी अलग-अलग शब्दावली के बावजूद, अंततः ये सभी एक ही चीज़ - एप्लिकेशन-विशिष्ट कोड को संदर्भित करते हैं जो एक श्रृंखला के नियमों को परिभाषित करता है।

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

ब्लॉकचेन की मूल बातें

कुछ संदर्भ से शुरू करते हैं। एक ऐसे अनुप्रयोग की कल्पना करें जो कई संगठनों द्वारा साझा किया गया है, जो एक अंतर्निहित डेटाबेस पर आधारित है। एक पारंपरिक केंद्रीकृत वास्तुकला में, इस डेटाबेस को एक ही पार्टी द्वारा होस्ट और प्रशासित किया जाता है, जो सभी प्रतिभागियों पर भरोसा करते हैं, भले ही वे एक दूसरे पर भरोसा न करें। डेटाबेस को संशोधित करने वाले लेन-देन केवल इस केंद्रीय पार्टी के सिस्टम पर अनुप्रयोगों द्वारा शुरू किए जाते हैं, अक्सर प्रतिभागियों से प्राप्त संदेशों के जवाब में। डेटाबेस बस वही करता है जो उसे बताया गया है क्योंकि आवेदन पर विश्वास किया जाता है केवल उसे लेनदेन भेजने के लिए भरोसा किया जाता है जो समझ में आता है।

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

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

सिद्धांत रूप में, किसी भी साझा डेटाबेस एप्लिकेशन को इसके मूल में ब्लॉकचैन का उपयोग करके आर्किटेक्चर किया जा सकता है। लेकिन ऐसा करने से कई तकनीकी चुनौतियां पैदा होती हैं जो केंद्रीकृत परिदृश्य में मौजूद नहीं हैं:

• लेन-देन के नियम। यदि कोई प्रतिभागी डेटाबेस को सीधे बदल सकता है, तो हम यह कैसे सुनिश्चित करें कि वे आवेदन के नियमों का पालन करें? एक उपयोगकर्ता को डेटाबेस की सामग्री को स्व-सेवारत तरीके से दूषित करने से रोकता है?
• नियतिवाद। एक बार जब ये नियम परिभाषित हो जाते हैं, तो उन्हें डेटाबेस की अपनी प्रति के लिए लेनदेन संसाधित करते समय कई नोड्स द्वारा कई बार लागू किया जाएगा। हम कैसे सुनिश्चित करते हैं कि प्रत्येक नोड बिल्कुल उसी परिणाम को प्राप्त करता है?
• संघर्ष की रोकथाम। केंद्रीय समन्वय के साथ, हम दो लेनदेन से कैसे निपटते हैं जो प्रत्येक आवेदन के नियमों का पालन करते हैं, लेकिन फिर भी एक दूसरे के साथ संघर्ष नहीं करते हैं? संघर्ष खेल प्रणाली को जानबूझकर करने की कोशिश से उपजा हो सकता है, या बुरी किस्मत और समय का निर्दोष परिणाम हो सकता है।

तो स्मार्ट कॉन्ट्रैक्ट, स्मार्ट फ़िल्टर और चिनकोड कहाँ से आते हैं? उनका मुख्य उद्देश्य इन चुनौतियों को हल करने के लिए एक ब्लॉकचेन के अंतर्निहित बुनियादी ढांचे के साथ काम करना है। स्मार्ट कॉन्ट्रैक्ट एप्लीकेशन कोड के विकेंद्रीकृत समकक्ष हैं - एक केंद्रीय स्थान पर चलने के बजाय, वे ब्लॉकचेन में कई नोड्स पर चलते हैं, जो उस डेटाबेस की सामग्री को संशोधित करने वाले लेनदेन का निर्माण या सत्यापन करते हैं।

आइए लेन-देन के नियमों के साथ शुरू करें, इन चुनौतियों में से सबसे पहले, और देखें कि उन्हें क्रमशः फैब्रिक, मल्टीचैन, एथेरियम और कॉर्डा में कैसे व्यक्त किया जाता है।

लेन-देन के नियम

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

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

इनपुट और आउटपुट

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

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

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

यह ध्यान दिया जाना चाहिए कि इनपुट-आउटपुट मॉडल साझा करने के बावजूद, मल्टीचैन और कॉर्डा इसे बहुत अलग तरीके से लागू करते हैं। मल्टीचैन में, आउटपुट में JSON, टेक्स्ट या बाइनरी प्रारूप में संपत्ति और / या डेटा हो सकता है। नियमों को "लेन-देन फिल्टर" या "स्ट्रीम फ़िल्टर" में परिभाषित किया गया है, जो सभी लेनदेन या केवल विशेष संपत्ति या डेटा के समूह को शामिल करने के लिए सेट किया जा सकता है। इसके विपरीत, एक कॉर्डा आउटपुट "स्टेट" को परिभाषित डेटा फ़ील्ड्स के साथ जावा या कोटलिन प्रोग्रामिंग भाषा में एक ऑब्जेक्ट द्वारा दर्शाया गया है। कॉर्डा के नियमों को "अनुबंध" में परिभाषित किया गया है, जो विशिष्ट राज्यों से जुड़ा हुआ है, और एक राज्य का अनुबंध केवल उन लेनदेन पर लागू होता है जिनमें उस राज्य में इसके इनपुट या आउटपुट होते हैं। यह कॉर्डा से संबंधित है असामान्य दृश्यता मॉडलजिसमें लेन-देन केवल उनके समकक्षों या जिनके बाद के लेनदेन को प्रभावित करते हैं, वे ही देख सकते हैं।

अनुबंध और संदेश

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

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

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

उदाहरण के नियम

आइए देखें कि इन दो मॉडलों के साथ एकल-परिसंपत्ति वित्तीय खाताधारक के लिए लेनदेन नियमों को कैसे लागू किया जाए। हमारे बहीखाता के डेटाबेस में प्रत्येक पंक्ति में दो कॉलम होते हैं, जिसमें स्वामी का पता और स्वामित्व वाली संपत्ति की मात्रा होती है। इनपुट-आउटपुट मॉडल में, लेनदेन को दो शर्तों को पूरा करना चाहिए:

1. किसी लेन-देन के आउटपुट में संपत्ति की कुल मात्रा को उसके इनपुट में कुल मिलाकर मिलान करना होता है। यह उपयोगकर्ताओं को मनमाने ढंग से पैसे बनाने या हटाने से रोकता है।
2. प्रत्येक लेनदेन को उसके प्रत्येक इनपुट के मालिक द्वारा हस्ताक्षरित करना होगा। यह उपयोगकर्ताओं को बिना अनुमति के एक दूसरे के पैसे खर्च करने से रोकता है।

एक साथ लिया गया, ये दो स्थितियाँ एक सरल लेकिन व्यवहार्य वित्तीय प्रणाली बनाने के लिए आवश्यक हैं।

अनुबंध-संदेश मॉडल में, परिसंपत्ति का अनुबंध एक "भुगतान भेजें" संदेश का समर्थन करता है, जो तीन पैरामीटर लेता है: प्रेषक का पता, प्राप्तकर्ता का पता, और भेजने के लिए मात्रा। जवाब में, अनुबंध निम्नलिखित चार चरणों को निष्पादित करता है:

1. सत्यापित करें कि लेनदेन को प्रेषक द्वारा हस्ताक्षरित किया गया था।
2. जांचें कि प्रेषक के पास पर्याप्त धन है।
3. प्रेषक की पंक्ति से अनुरोधित मात्रा घटाएं।
4. उस मात्रा को प्राप्तकर्ता की पंक्ति में जोड़ें।

यदि पहले दो चरणों में से कोई भी चेक विफल हो जाता है, तो अनुबंध समाप्त हो जाएगा और कोई भुगतान नहीं किया जाएगा।

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

यह पता लगाने के लिए यहां हमारे दायरे से परे है कि इन दोनों मॉडलों के बीच विकल्पों को कैसे प्रभावित करना चाहिए। लेकिन एक सामान्य दिशानिर्देश के रूप में, जब एक नया ब्लॉकचैन एप्लिकेशन विकसित हो रहा है, तो यह दोनों रूपों में अपने लेनदेन नियमों को व्यक्त करने की कोशिश कर रहा है, और यह देखना कि कौन अधिक स्वाभाविक रूप से फिट बैठता है। अंतर खुद को व्यक्त करेगा: (ए) प्रोग्रामिंग की आसानी, (बी) भंडारण आवश्यकताओं और थ्रूपुट, और (सी) संघर्ष का पता लगाने की गति। हम इस अंतिम मुद्दे पर बाद में बात करेंगे।

बिल्ट-इन नियम

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

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

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

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

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

लेन-देन के नियम	कपड़ा	मल्टीचेन	Ethereum	रस्सी
आदर्श	अनुबंध-संदेश	इनपुट आउटपुट	अनुबंध-संदेश	इनपुट आउटपुट
निर्मित-इन	कोई नहीं	अनुमतियाँ + संपत्ति + धाराएँ	कोई नहीं	कोई नहीं

नियतिवाद

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

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

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

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

गैर-निर्धारणवाद के स्रोत

ब्लॉकचेन कोड में गैर-नियतत्ववाद स्पष्ट रूप से एक समस्या है। लेकिन अगर गणना के बुनियादी भवन, जैसे अंकगणितीय, नियतात्मक हैं, तो हमें क्या चिंता करनी होगी? खैर, यह पता चला, काफी कुछ बातें:

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

हमारे चार ब्लॉकचैन प्लेटफ़ॉर्म इन नुकसानों से बचने के लिए कई अलग-अलग तरीकों का इस्तेमाल करते हैं।

नियतात्मक निष्पादन

आइए Ethereum से शुरू करते हैं, क्योंकि इसका दृष्टिकोण सबसे "शुद्ध" है। Ethereum कॉन्ट्रैक्ट्स को “Ethereum bytecode” नामक एक विशेष-प्रयोजन प्रारूप में व्यक्त किया जाता है, जिसे Ethereum Virtual Machine (“EVM”) द्वारा निष्पादित किया जाता है। प्रोग्रामर सीधे बायटेकोड नहीं लिखते हैं, बल्कि इसे सॉलिडिटी नामक एक जावास्क्रिप्ट जैसी प्रोग्रामिंग भाषा से उत्पन्न या "संकलित" करते हैं। (अन्य भाषाएं उपलब्ध हुआ करती थीं लेकिन तब से अब तक समाप्त हो चुकी हैं।) निर्धारकता की गारंटी इस तथ्य से दी जाती है कि सॉलिडिटी और एथेरियम बायटेकोड किसी भी गैर-नियतात्मक संचालन को सांकेतिक नहीं कर सकता है - यह इतना आसान है।

मल्टीचैन फिल्टर और कॉर्डा कॉन्ट्रैक्ट्स मौजूदा प्रोग्रामिंग लैंग्वेज और रनटाइम एनवायरनमेंट को अडॉप्ट करके एक अलग तरीका चुनते हैं। मल्टीचिन गूगल में चल रहे जावास्क्रिप्ट का उपयोग करता है V8 इंजन, जो क्रोम ब्राउज़र और Node.js प्लेटफ़ॉर्म का कोर भी बनाता है, लेकिन गैर-नियतांक के स्रोतों के साथ अक्षम। इसी तरह, कॉर्डा जावा या का उपयोग करता है Kotlinदोनों को "जावा बाइटकोड" के लिए संकलित किया गया है जो जावा वर्चुअल मशीन ("जेवीएम") के भीतर निष्पादित होता है। अभी के लिए, कॉर्ड ओरेकल के मानक गैर-नियतात्मक जेवीएम का उपयोग करता है, लेकिन एक को एकीकृत करने के लिए काम चल रहा है नियतात्मक संस्करण। इस बीच, कॉर्डा अनुबंध डेवलपर्स को अपने कोड में गैर-नियतत्ववाद की अनुमति नहीं देने का ध्यान रखना चाहिए।

इथेरियम की शुद्धतावाद की तुलना मल्टीचैनल और कॉर्डा द्वारा लिए गए विकासवादी दृष्टिकोण से कैसे की जाती है? एथेरियम के लिए मुख्य लाभ जोखिम न्यूनीकरण है - एक अंतर्निहित उद्देश्य वाली आभासी मशीन में गैर-नियतात्मकता का एक अनजाने स्रोत होने की संभावना कम होती है। जबकि इस तरह के किसी भी निरीक्षण को सॉफ़्टवेयर अपडेट द्वारा तय किया जा सकता है, यह किसी भी श्रृंखला के लिए विघटनकारी होगा जो इसे मुठभेड़ करने के लिए पर्याप्त रूप से अशुभ था। एथेरियम की समस्या, हालांकि, यह है कि सॉलिडिटी और ईवीएम प्रोग्रामिंग भाषाओं और रनटाइम वातावरण के व्यापक संदर्भ में एक छोटे और नवजात पारिस्थितिकी तंत्र का गठन करते हैं। तुलना करके, जावास्क्रिप्ट और जावा हैं गितुब पर शीर्ष दो भाषाएँ, अरबों डिजिटल उपकरणों पर चलते हैं, और ऐसे रनटाइम होते हैं जिन्हें दशकों से अनुकूलित किया गया है। संभवत: यही कारण है कि सार्वजनिक Ethereum ब्लॉकचेन एक संक्रमण पर विचार कर रहा है ईडब्ल्यूएएसएम, उभरते WebAssembly मानक का एक नियतात्मक कांटा।

समर्थन द्वारा नियतत्ववाद

जब यह नियतत्ववाद की बात आती है, तो हाइपरलेगर फैब्रिक पूरी तरह से अलग दृष्टिकोण अपनाता है। फैब्रिक में, जब "क्लाइंट" नोड कुछ चैनकोड को संदेश भेजना चाहता है, तो वह पहले उस संदेश को कुछ "एंडोर्सर" नोड्स में भेजता है। इनमें से प्रत्येक नोड संदेश की राय बनाते हुए, स्वतंत्र रूप से चैंकोड को निष्पादित करता है प्रभाव उस चिनकोड के डेटाबेस पर। इन विचारों को ग्राहक को एक डिजिटल हस्ताक्षर के साथ वापस भेजा जाता है जो एक औपचारिक "समर्थन" का गठन करता है। यदि क्लाइंट को इच्छित परिणाम के पर्याप्त समर्थन प्राप्त होते हैं, तो यह उन एंडोर्समेंट वाले लेनदेन का निर्माण करता है, और इसे श्रृंखला में शामिल करने के लिए प्रसारित करता है।

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

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

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

इस लचीलेपन के लिए फैब्रिक क्या कीमत अदा करता है? यदि ब्लॉकचेन का उद्देश्य एक साझा डेटाबेस-संचालित एप्लिकेशन से बिचौलियों को दूर करना है, तो एंडोर्सर्स पर फैब्रिक की निर्भरता उस लक्ष्य से एक बड़ा कदम दूर ले जाती है। श्रृंखला में भाग लेने वालों के लिए, अब चिनकोड के नियमों का पालन करना पर्याप्त नहीं है - उन्हें यह मानने के लिए कुछ अन्य नोड्स की भी आवश्यकता है कि उन्होंने ऐसा किया है। इससे भी बदतर, एंडोर्सर्स का एक दुर्भावनापूर्ण सबसेट डेटाबेस परिवर्तनों को मंजूरी दे सकता है जो चिनकोड का पालन नहीं करते हैं। यह नियमित ब्लॉकचेन में सत्यापनकर्ताओं की तुलना में बहुत अधिक शक्ति देता है, जो लेनदेन को रोक सकता है लेकिन ब्लॉकचेन के नियमों का उल्लंघन नहीं कर सकता है। ब्लॉकचेन एप्लिकेशन डेवलपर्स को यह तय करना होगा कि यह व्यापार बंद उनके विशेष मामले में समझ में आता है या नहीं।

नियतिवाद	कपड़ा	मल्टीचेन	Ethereum	रस्सी
आदर्श	पृष्ठांकन	अनुकूलित रनटाइम	उद्देश्य-निर्मित वी.एम.	अनुकूलित रनटाइम
भाषाऐं	गो + जावा + जावास्क्रिप्ट	जावास्क्रिप्ट	दृढ़ता	जावा + कोटलिन
कोड दृश्यता	प्रतिपक्ष + समर्थन करते हैं	ब्लॉक श्रृंखला	ब्लॉक श्रृंखला	प्रतिपक्ष + आश्रितों
बलपूर्वक	नहीं	हाँ	हाँ	अभी के लिए नहीं)

संघर्ष की रोकथाम

अब तक, हमने चर्चा की है कि विभिन्न ब्लॉकचैन प्लेटफ़ॉर्म कोड में लेनदेन नियमों को कैसे व्यक्त करते हैं, और वे कैसे निर्धारक रूप से यह सुनिश्चित करते हैं कि प्रत्येक नोड उन लोगों पर पहचान के साथ लागू होता है। अब हमारे तसलीम के तीसरे पहलू के बारे में बात करने का समय है: प्रत्येक प्लेटफ़ॉर्म इस संभावना से कैसे निपटता है कि दो लेनदेन, जो अपने आप में मान्य हैं और एक दूसरे के साथ संघर्ष करते हैं? सबसे सरल उदाहरण में, कल्पना कीजिए कि एलिस के पास एक वित्तीय बहीखाता में $ 10 है और दो लेनदेन प्रसारित करता है - एक $ 8 को बॉब भेज रहा है, और दूसरा चार्ली को $ 7 भेज रहा है। स्पष्ट रूप से, इनमें से केवल एक लेनदेन को सफल होने दिया जा सकता है।

दो मॉडल

हम मल्टीचेन और कॉर्डा के इस समस्या के दृष्टिकोण को एक साथ जोड़कर शुरू कर सकते हैं। जैसा कि पहले वर्णित है, ये दोनों लेनदेन और उनके नियमों का प्रतिनिधित्व करने के लिए एक इनपुट-आउटपुट मॉडल का उपयोग करते हैं, जिसमें प्रत्येक लेनदेन इनपुट पिछले लेनदेन आउटपुट को खर्च करता है। यह संघर्षों को रोकने के लिए एक सरल सिद्धांत की ओर जाता है: प्रत्येक आउटपुट केवल एक बार खर्च किया जा सकता है। मल्टीचैन फिल्टर और कॉर्डा कॉन्ट्रैक्ट इस प्रतिबंध को पूरी तरह लागू करने के लिए अपने संबंधित प्लेटफॉर्म पर भरोसा कर सकते हैं। चूंकि ऐलिस $ 10 को पिछले लेनदेन आउटपुट द्वारा दर्शाया गया है, इसलिए यह एकल-व्यय नियम स्वतः ही बॉब और चार्ली दोनों को भेजना बंद कर देता है।

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

चलिए इथेरियम की ओर बढ़ते हैं। याद करने के लिए, Ethereum इनपुट और आउटपुट के बजाय कॉन्ट्रैक्ट और मैसेजेस का उपयोग करता है। परिणामस्वरूप, एलिस के दो भुगतान जैसे लेनदेन तुरंत ब्लॉकचैन इंजन के लिए दिखाई नहीं देते हैं। इसके बजाय, वे पता लगाते हैं और अवरुद्ध कर देते हैं अनुबंध चेन पर उनके आदेश की पुष्टि होने के बाद, जो लेनदेन की प्रक्रिया करता है। एलिस के प्रत्येक भुगतान को संसाधित करते समय, अनुबंध सत्यापित करता है कि उसका संतुलन पर्याप्त है या नहीं। यदि $ 8 से बॉब का भुगतान करने वाला लेनदेन पहले आता है, तो इसे हमेशा की तरह संसाधित किया जाएगा, जिससे ऐलिस उसके खाते में $ 2 के साथ जाएगी। नतीजतन, जब अनुबंध चार्ली को $ 7 का भुगतान करने वाले दूसरे लेनदेन की प्रक्रिया करता है, तो यह देखता है कि ऐलिस में आवश्यक धन और लेनदेन की कमी है।

आउटपुट बनाम अनुबंध

अब तक हमने परस्पर विरोधी लेनदेन को रोकने के लिए दो अलग-अलग तकनीकों को देखा है - मल्टीचिन और कॉर्डा में एकल-आउटपुट आउटपुट और एथेरियम में अनुबंध-आधारित सत्यापन। तो कौन सा बेहतर है?

इस प्रश्न का उत्तर देने में मदद करने के लिए, आइए एक उदाहरण पर विचार करें "1-ऑफ -2 मल्टीसिग्नेचर", जो गैविन और हेलेन की ओर से $ 100 का है, और दोनों में से उस पैसे को स्वतंत्र रूप से खर्च करने की अनुमति देता है। गेविन अपने आवेदन को डोना को $ 80 का भुगतान करने का निर्देश देता है, और कुछ सेकंड बाद हेलेन एडवर्ड को $ 40 भेजना चाहता है। चूंकि दोनों भुगतानों के लिए अपर्याप्त धन हैं, इसलिए ये लेनदेन अनिवार्य रूप से संघर्ष करेंगे। इस घटना में कि दोनों लेन-देन प्रसारित किए जाते हैं, परिणाम जो भी इसे पहले श्रृंखला में बनाता है द्वारा निर्धारित किया जाएगा। ध्यान दें कि ऐलिस के उदाहरण के विपरीत, यह संघर्ष है आकस्मिक, क्योंकि कोई भी आवेदन के नियमों को तोड़ने की कोशिश नहीं कर रहा है - उनके पास बस अशुभ समय था।

इस संघर्ष की संभावना पर विचार करते हुए, महत्वपूर्ण सवाल यह है: गेविन द्वारा अपना लेनदेन भेजने के बाद, हेलेन के नोड को यह जानने में कितना समय लगेगा कि उसका भुगतान विफल हो सकता है? यह अवधि जितनी कम होगी, हेलेन को उस भुगतान का प्रयास करने से रोका जा सकता है, उसे और उसके आवेदन को बाद के आश्चर्य से बचाया जा सकता है।

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

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

लेकिन हमें इससे यह निष्कर्ष नहीं निकालना चाहिए कि इनपुट-आउटपुट मॉडल हमेशा सबसे अच्छा काम करता है। हमारे उदाहरण परिदृश्य पर एक भिन्नता पर विचार करें, जहां गेविन और हेलेन दोनों $ 40 के मूल शेष से $ 100 के भुगतान का अनुरोध करते हैं, ठीक उसी समय। इनपुट-आउटपुट मॉडल में ये लेनदेन संघर्ष करेगा, क्योंकि वे दोनों एक ही डेटाबेस पंक्ति खर्च कर रहे हैं जिसमें $ 100 है, और केवल एक भुगतान सफल होगा। लेकिन Ethereum में, दोनों लेन-देन को सफलतापूर्वक संसाधित किया जाएगा, भले ही उनके अंतिम आदेश के बावजूद, खाते में दोनों के लिए पर्याप्त धन हो। इस मामले में, एथेरियम गैविन और हेलेन के इरादों को अधिक विश्वासपूर्वक पूरा करता है।

पढ़ने-लिखने के सेट

अंत में, फैब्रिक के बारे में बात करते हैं, जिसका समर्थन-आधारित दृष्टिकोण इन दो तकनीकों का एक संकर है। जैसा कि पहले बताया गया है, जब एक फैब्रिक “क्लाइंट” नोड एक कॉन्ट्रैक्ट को एक संदेश भेजना चाहता है, तो वह पहले उस संदेश को निष्पादित करने के लिए कुछ एंडोर्सिंग नोड्स से पूछता है। एंडोर्सिंग नोड्स Ethereum के समान तरीके से ऐसा करते हैं - अपने स्थानीय डेटाबेस के खिलाफ अनुबंध चला रहे हैं - लेकिन यह प्रक्रिया तुरंत लागू होने के बजाय देखी जाती है। प्रत्येक एंडोर्सर उस पंक्तियों के सेट को रिकॉर्ड करता है जिसे पढ़ा और लिखा जाएगा, उस समय में उन पंक्तियों का सटीक संस्करण भी नोट करेगा। संस्करणित पंक्तियों के इस "रीड-राइट सेट" को स्पष्ट रूप से बेचान में संदर्भित किया गया है, और लेनदेन में शामिल किया गया है जो क्लाइंट को विदेशी करता है।

श्रृंखला में उनके ऑर्डर को अंतिम रूप देने के बाद फैब्रिक लेनदेन के बीच के विवादों को हल किया जाता है। प्रत्येक नोड प्रत्येक लेनदेन को स्वतंत्र रूप से संसाधित करता है, बेचान नीतियों की जांच करता है और निर्दिष्ट डेटाबेस परिवर्तनों को लागू करता है। हालाँकि, यदि कोई लेन-देन एक डेटाबेस पंक्ति संस्करण को पढ़ता या लिखता है जो पहले से किसी पिछले लेन-देन द्वारा संशोधित किया जा चुका है, तो उस दूसरे लेनदेन को अनदेखा कर दिया जाता है। बॉब और चार्ली के पास ऐलिस के परस्पर विरोधी भुगतान पर वापस जाने के लिए, ये दोनों लेन-देन उसी पंक्ति संस्करण को पढ़ेंगे और संशोधित करेंगे, जिसमें $ 10 होगा, जिसके साथ ऐलिस शुरू हुई। तो दूसरा लेनदेन सुरक्षित और स्वचालित रूप से निरस्त हो जाएगा।

संघर्ष समाधान के लिए फैब्रिक का दृष्टिकोण ठीक काम करता है, लेकिन प्रदर्शन और लचीलेपन के मामले में यह पिछले दो मॉडलों में से सबसे खराब है। क्योंकि समर्थन लेन-देन को विशिष्ट रीड-राइट सेटों में परिवर्तित करते हैं, गैविन और हेलेन के एक साथ लेकिन अनुकूल $ 40 भुगतान एक संघर्ष का कारण बनते हैं जो एथेरियम से बचा जाता है। हालाँकि, फैब्रिक इनपुट-आउटपुट मॉडल का गति लाभ प्राप्त नहीं करता है, क्योंकि एंडोर्सर्स ब्लॉकचेन द्वारा पुष्टि किए गए डेटाबेस के सबसे हाल के संस्करण के खिलाफ अनुबंधों को निष्पादित करते हैं, अपुष्ट लेनदेन की अनदेखी करते हैं। इसलिए यदि हेवन गैविन के कुछ सेकंड बाद अपना भुगतान शुरू करता है, लेकिन ब्लॉकचेन पर गेविन की पुष्टि होने से पहले, फैब्रिक परस्पर विरोधी लेन-देन बनाएगा जो कि शुद्ध इनपुट-आउटपुट मॉडल से बचा जाता है।

संघर्ष की रोकथाम	कपड़ा	मल्टीचेन	Ethereum	रस्सी
आदर्श	पढ़ने-लिखने के सेट	एकल खर्च	संविदा जाँच	एकल खर्च
सत्यापन	स्वतंत्र	स्वतंत्र	स्वतंत्र	विश्वसनीय नोटरी
गति	~ 10s (पुष्टि)	~ 1s (प्रचार)	~ 10s (पुष्टि)	0 ~ 5 एस (नोटरी)

एक जटिल विकल्प

इस टुकड़े में, हमने कई अलग-अलग तरीकों की समीक्षा की है जिसमें कॉर्डा, एथेरियम, फैब्रिक और मल्टीचैन "स्मार्ट कॉन्ट्रैक्ट्स" या एप्लिकेशन कोड की प्रमुख चुनौतियों को संबोधित करते हैं, जो एक ब्लॉकचेन में एम्बेडेड है। और प्रत्येक प्लेटफ़ॉर्म पर हमारे तीन मुख्य प्रश्नों के अलग-अलग उत्तर हैं: लेनदेन नियमों का प्रतिनिधित्व कैसे किया जाता है? कोड को निर्धारक रूप से कैसे निष्पादित किया जाता है? और हम टकराव को कैसे रोकते हैं?

तो हमारे स्मार्ट कॉन्ट्रैक्ट शोडाउन का विजेता कौन है? यह अब तक स्पष्ट होना चाहिए कि कोई सरल उत्तर नहीं है। प्रत्येक प्लेटफ़ॉर्म लचीलापन, सरलता, प्रदर्शन, निर्बाधता, सुरक्षा और गोपनीयता के बीच एक जटिल बहु-मार्ग व्यापार का प्रतिनिधित्व करता है। तो किसी विशेष एप्लिकेशन के लिए प्लेटफ़ॉर्म का चुनाव उस एप्लिकेशन के ट्रस्ट मॉडल की विस्तृत समझ के साथ शुरू होता है, इसमें शामिल लेनदेन के प्रकार और उनके संघर्ष के संभावित पैटर्न। यदि आप किसी को इन सवालों के जवाब जानने से पहले किसी विशिष्ट स्मार्ट कॉन्ट्रैक्ट सॉल्यूशन को आगे बढ़ाते हुए पाते हैं, तो मैं विनम्रता से सुझाव देता हूं लेकिन जोर देकर कहता हूं कि वे "स्मार्ट" दृष्टिकोण अपनाएं।

कृपया कोई टिप्पणी पोस्ट करें लिंक्डइन पर.