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

यहां ब्लॉकचेन क्यों है?

शुरू करने के लिए, ब्लॉकचैन के बारे में लेखों के लेखकों से शायद ही कभी पूछा जाता है: क्या इस स्थिति में ब्लॉकचैन की आवश्यकता है? मौखिक अनुबंध या कानूनी अनुबंध के साथ क्या कार्य हल करना मुश्किल है, लेकिन बस एक ब्लॉकचेन के साथ?

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

इस दृष्टिकोण के कई नुकसान हैं।

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

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

कार्यान्वयन

विवाद को नियंत्रित करने वाले नियमों का एक सेट विभिन्न तरीकों से लागू किया जा सकता है। नीचे हम बात करेंगे कि हमने स्मार्टज़ प्लेटफॉर्म के उपयोगकर्ताओं के लिए क्या किया।

विवाद में दो पक्ष शामिल हैं। Ethereum नेटवर्क पर कॉन्ट्रैक्ट की कॉपी बनाने वाले को कॉन्ट्रैक्ट का मालिक (Owner) कहा जाता है, और उसके प्रतिद्वंद्वी को प्रतिद्वंद्वी (Opponent) कहा जाता है। अनुबंध के मालिक ने एक शाब्दिक कथन निर्धारित किया है जिसे वह सत्य मानता है। विरोधी यह शर्त लगा रहा है कि बयान गलत है। विवाद के परिणाम पर निर्णय एक स्वतंत्र मध्यस्थ (आर्बिटर) द्वारा किया जाता है, जिसकी उम्मीदवारी को मालिक और प्रतिद्वंद्वी दोनों द्वारा अनुमोदित किया जाता है। मध्यस्थ मध्यस्थ को विवाद की राशि के प्रतिशत के रूप में एक कमीशन प्राप्त करता है।

अनुबंध का काम कई क्रमिक चरणों में विभाजित है।

1. वार्ता मालिक और प्रतिद्वंद्वी, अनुबंध के निर्माण से पहले भी, किसी भी सुविधाजनक तरीके से बातचीत कर सकते हैं। संयुक्त रूप से यह तय करने के बाद कि मध्यस्थ कौन होगा, वे उम्मीदवार को अपने विवाद का न्याय करने के लिए निमंत्रण भेजते हैं। निमंत्रण मिलने पर, मध्यस्थ सभी शर्तों और इसी स्थिति को देखेंगे। नीचे इस पर और अधिक, लेकिन अब यह समझना महत्वपूर्ण है कि भविष्य के मध्यस्थ को यह संख्या अनुबंध में स्थानांतरित करनी चाहिए ताकि वह यह दिखा सके कि वह किन परिस्थितियों में वादकारियों का न्याय करने के लिए तैयार है। यदि मालिक ने सुरक्षा जमा (ArbiterPenaltyAmount) की गैर-शून्य राशि स्थापित की है, तो, शर्तों के अनुसार, मध्यस्थ को अनुबंधित एयरटाइम की अनुबंधित राशि को हस्तांतरित करना होगा, जिसके बाद यह तब तक अवरुद्ध हो जाता है जब तक मध्यस्थ वाद-विवाद करने वाले या विवाद के निपटारे की समयसीमा तय नहीं करता। बाद के मामले में, मध्यस्थ सुरक्षा जमा को वापस लेने का अवसर खो देता है, और यह राशि विवाद के लिए पार्टियों के बीच समान रूप से वितरित की जाती है।
2. इनिशियलाइज़ेशन । अनुबंध का मालिक अनुबंध का एक उदाहरण बनाता है और इसके मापदंडों को निर्धारित करता है: विवाद का विषय; वह तिथि जिसके आधार पर मध्यस्थ को तय करना होगा (समय सीमा); मध्यस्थता आयोग प्रतिशत (आंशिक संख्या and 0 और <100); जमानत की राशि (शून्य हो सकती है), जिसे मध्यस्थ को इस बात की गारंटी देनी चाहिए कि वह मौजूदा शब्दकरण में विवाद का फैसला सही समय पर करने के लिए करता है। मालिक उस मध्यस्थ का पता भी निर्धारित करता है जिस पर वह भरोसा करता है। इस पते का केवल स्वामी ही बाद में मध्यस्थ बन सकेगा।
3. मालिक दर सेट करने के बाद, अनुबंध धारक एक शर्त लगाता है। ऐसा करने के लिए, वह अनुबंध के लिए ईथर की किसी भी राशि को भेजता है। यह राशि दर है, यह अनुबंध के पते पर अवरुद्ध है।
4. मध्यस्थ की सहमति । मालिक की बोली विवाद की शर्तों को ठीक करती है। अब मध्यस्थ लेन-देन की पूरी शर्तें देखता है: विवाद का शब्दांकन, उस समय से पहले जब कोई निर्णय लेने की आवश्यकता होती है, और सबसे महत्वपूर्ण बात, वह समझ सकता है कि इनाम के रूप में वह कितना ईथर प्राप्त करेगा। यदि मध्यस्थ सब कुछ से खुश है, तो वह अपनी भागीदारी की पुष्टि करता है और उसी समय बीमा जमा को स्थानांतरित करता है।
5. एक प्रतिद्वंद्वी के लिए खोजें । मध्यस्थ की सहमति के बाद, प्रतिद्वंद्वी की तलाश शुरू होती है। मालिक प्रतिद्वंद्वी के पते को अग्रिम में सेट करता है, यदि वह किसी विशिष्ट व्यक्ति के साथ केवल बहस करने के लिए तैयार है, या पते को खाली छोड़ देता है, और फिर नेटवर्क पर किसी भी पते का मालिक (मध्यस्थ और मालिक को छोड़कर) प्रतिद्वंद्वी बन सकता है। प्रतिद्वंद्वी अनुबंध की एक अलग विधि को कॉल करके विवाद में भागीदारी की पुष्टि करता है, जिसके लिए वह डेटा के वर्तमान संस्करण संख्या को प्रसारित करता है और प्रसारण करता है - जितना मालिक ने निर्धारित किया है। इस क्षण से, शर्त को समापन माना जाता है। अब अनुबंध या तो मध्यस्थ या अंतिम तिथि के फैसले का इंतजार कर रहा है।
6. विवाद का परिणाम । मध्यस्थ तीन तरीकों से विवाद का न्याय कर सकता है।
   - कथन को सत्य मानें। इस मामले में, अनुबंध के मालिक मध्यस्थ की पूरी राशि निकाल सकते हैं, मध्यस्थ और सुरक्षा जमा के कमीशन को छोड़कर (यदि यह था): धन को मध्यस्थ द्वारा वापस ले लिया जाता है, और प्रतिद्वंद्वी को कुछ भी नहीं मिलता है।
   - कथन को गलत मानें। इस मामले में, मध्यस्थ उसकी वजह से प्रतिज्ञा की राशि और प्रतिज्ञा की राशि में ईथर को वापस ले सकता है। प्रतिद्वंद्वी आराम लेता है, लेकिन मालिक को कुछ भी नहीं मिलता है।
   - विवाद को अघुलनशील घोषित करें। उदाहरण के लिए, मालिक ने बयान के साथ विवाद पैदा किया "अगले रविवार के लिए निर्धारित टीमों ए और बी के बीच फुटबॉल मैच, ए के पक्ष में 2: 1 के स्कोर के साथ समाप्त होगा।" यदि मैच रद्द हो जाता है, तो रेफरी विवाद को हल नहीं करेगा, लेकिन उसे अपनी प्रतिज्ञा लेने में सक्षम होना चाहिए, क्योंकि समस्या उसकी गलती के माध्यम से नहीं हुई थी। इस मामले में, प्रत्येक पक्ष अनुबंध के पते से अपने बटुए में अपनी बोली की राशि में हवा के हस्तांतरण का अनुरोध कर सकता है।
7. धन की निकासी । जब मध्यस्थ ने निर्णय लिया है या समय सीमा की तारीख आ गई है, तो प्रत्येक पक्ष हवा पर एक निष्कर्ष का अनुरोध कर सकता है। उत्पादन के लिए कितना ईथर, अनुबंध स्वयं गणना करेगा, विवाद के परिणामों पर ध्यान केंद्रित करेगा।
8. अनुबंध का विनाश । मालिक अनुबंध के लिए एक स्वयं-विनाश कमांड भेज सकता है। यह या तो लेनदेन के समापन से पहले किया जा सकता है (यदि मध्यस्थ नहीं मिला), या इसके पूरा होने के बाद (यदि सभी दलों ने उन पर बकाया धन वापस ले लिया)। ऐसा अवसर उपयोगी होगा यदि, जादुई तरीके से, अनुबंध के पते पर प्राप्त की गई हवा की तुलना में अधिक हो। इस तरह की घटना की संभावना बहुत कम है, लेकिन अभी भी एथेरियम में प्रसारण के हस्तांतरण को एक मनमाने अनुबंध के पते पर पूरी तरह से रोकना असंभव है, और जमे हुए पैसे फेंकना मूर्खतापूर्ण है।

अब थोड़ा राज्य संस्करण संख्या की आवश्यकता क्यों है। यह वह संख्या है जो विवाद की महत्वपूर्ण स्थितियों में प्रत्येक परिवर्तन के साथ बढ़ती है, जैसे विवाद का शब्दांकन, मध्यस्थों का कमीशन या जुर्माना। जब कोई विवाद की शर्तों से सहमत होता है, तो वह 1) डेटा की वर्तमान स्थिति को देखता है; 2) अनुबंध विधि के लिए एक कॉल भेजता है, जो शर्तों की स्वीकृति का पंजीकरण करता है। यदि इन दोनों घटनाओं में से एक पक्ष (सबसे अधिक संभावना है, मालिक) अनुबंध के पैरामीटर को बदलता है, तो आप डेटा के अन्य संस्करण से सहमत होंगे। उदाहरण के लिए, एक रेफरी उम्मीदवार smartz.io पर अनुबंध इंटरफ़ेस में प्रवेश करता है और देखता है कि उसे 1% (लगभग $ 30) के कमीशन के लिए 10 ईथर (आज यह लगभग 3,000 डॉलर) पर विवाद का न्याय करने की पेशकश की जा रही है। उम्मीदवार खुशी से सहमत है और नेटवर्क को पुष्टिकरण लेनदेन भेजता है। बेईमान मालिक खनन पूल में आर्बिटर के कच्चे लेनदेन को देखता है और अपना खुद का भेजता है: आर्बिटर के पारिश्रमिक को 0% से बदलता है। एक धोखेबाज गैस की कीमत औसत से ऊपर रखता है, और कुछ संभावना के साथ खनिक पहले अपने लेनदेन की प्रक्रिया कर सकते हैं। इस तरह के हमले को फ्रंट रनिंग अटैक कहा जाता है। स्टेट वर्जन नंबर इससे बचाता है। यदि मालिक-कीट लेनदेन को पहले से संसाधित किया जाता है, तो अनुबंध में डेटा की संस्करण संख्या बदल जाएगी। उनके लेनदेन में मध्यस्थ ने डेटा की संस्करण संख्या को एक कम भेजा। इसलिए, अनुबंध लेनदेन को पूरा करने से इनकार कर देगा, एक रोलबैक होगा। मध्यस्थ नई स्थितियों की समीक्षा करेगा और डेटा के वर्तमान संस्करण संख्या को भेजकर या भाग लेने या सहमत होने से इनकार करेगा।

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

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

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

परीक्षण

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

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

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

सारांश

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

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

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

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

लिंक

• गिटहब: बेटमे स्मार्ट अनुबंध https://github.com/smartzplatform/betme-ether
• बेटमे - स्मार्टज़ प्लेटफार्म विकी https://wiki.smartz.io/betme
• टोकन-क्यूरेट रजिस्ट्रियां 1.0 (टोकन-प्रबंधित रजिस्ट्रियां 1.0) https://habr.com/company/mixbytes/blog/418711/
• मेटामास्क एक्सटेंशन https://metamask.io
• ट्रस्ट - Ethereum & ERC20 वॉलेट https://trustwalletapp.com