इथेरियम श्वेतपत्रिका

हा पेपर अनेक वर्षे जुना असला तरी, आम्ही खालील मूळ पेपर तसाच ठेवला आहे कारण तो एक उपयुक्त संदर्भ आणि इथेरियम व त्याच्या दृष्टिकोनाचे अचूक प्रतिनिधित्व म्हणून काम करत राहतो.

पुढच्या पिढीचे स्मार्ट कॉन्ट्रॅक्ट आणि विकेंद्रित ॲप्लिकेशन प्लॅटफॉर्म

2009 मध्ये सातोशी नाकामोटोने विकसित केलेले बिटकॉइन हे पैसा आणि चलनातील एक मूलगामी प्रगती म्हणून अनेकदा गौरविले गेले आहे, कारण हे अशा डिजिटल मालमत्तेचे पहिले उदाहरण आहे ज्याला एकाच वेळी कोणताही आधार किंवा "अंगभूत मूल्य (opens in a new tab)" नाही आणि कोणताही केंद्रीकृत जारीकर्ता किंवा नियंत्रक नाही. तथापि, बिटकॉइन प्रयोगाचा दुसरा, आणि कदाचित अधिक महत्त्वाचा भाग म्हणजे त्यामागील ब्लॉकचेन तंत्रज्ञान जे वितरित एकमताचे साधन आहे, आणि आता बिटकॉइनच्या या दुसऱ्या पैलूकडे वेगाने लक्ष वळू लागले आहे. ब्लॉकचेन तंत्रज्ञानाच्या सामान्यतः उद्धृत केलेल्या पर्यायी ॲप्लिकेशन्समध्ये कस्टम चलने आणि आर्थिक साधनांचे प्रतिनिधित्व करण्यासाठी ऑन-ब्लॉकचेन डिजिटल मालमत्तेचा वापर करणे ("कलर्ड कॉइन्स (opens in a new tab)"), अंतर्निहित भौतिक उपकरणाची मालकी ("स्मार्ट प्रॉपर्टी (opens in a new tab)"), डोमेन नावांसारख्या नॉन-फंजिबल मालमत्ता ("Namecoin (opens in a new tab)"), तसेच अनियंत्रित नियमांची अंमलबजावणी करणाऱ्या कोडच्या तुकड्याद्वारे थेट नियंत्रित केल्या जाणाऱ्या डिजिटल मालमत्तेचा समावेश असलेले अधिक जटिल ॲप्लिकेशन्स ("स्मार्ट कॉन्ट्रॅक्ट्स (opens in a new tab)") किंवा ब्लॉकचेन-आधारित "विकेंद्रित स्वायत्त संस्था (opens in a new tab)" (DAOs) यांचा समावेश होतो. इथेरियमचा उद्देश अशी ब्लॉकचेन प्रदान करणे आहे ज्यामध्ये अंगभूत, पूर्ण विकसित ट्युरिंग-कंप्लीट प्रोग्रामिंग भाषा असेल, ज्याचा वापर "कॉन्ट्रॅक्ट्स" तयार करण्यासाठी केला जाऊ शकतो जे अनियंत्रित स्थिती संक्रमण कार्ये (state transition functions) एन्कोड करण्यासाठी वापरले जाऊ शकतात, ज्यामुळे वापरकर्त्यांना केवळ काही ओळींच्या कोडमध्ये लॉजिक लिहून वर वर्णन केलेल्या कोणत्याही प्रणाली, तसेच अशा अनेक प्रणाली ज्यांची आपण अद्याप कल्पनाही केलेली नाही, तयार करण्याची अनुमती मिळते.

बिटकॉइन आणि विद्यमान संकल्पनांचा परिचय

इतिहास

विकेंद्रित डिजिटल चलनाची संकल्पना, तसेच मालमत्ता नोंदणीसारखे पर्यायी ॲप्लिकेशन्स, अनेक दशकांपासून अस्तित्वात आहेत. 1980 आणि 1990 च्या दशकातील निनावी ई-कॅश प्रोटोकॉल, जे प्रामुख्याने Chaumian blinding म्हणून ओळखल्या जाणाऱ्या क्रिप्टोग्राफिक प्रिमिटिव्हवर अवलंबून होते, त्यांनी उच्च दर्जाची गोपनीयता असलेले चलन प्रदान केले, परंतु केंद्रीकृत मध्यस्थावरील त्यांच्या अवलंबनामुळे हे प्रोटोकॉल मोठ्या प्रमाणावर लोकप्रियता मिळवण्यात अपयशी ठरले. 1998 मध्ये, वेई दाई यांचे b-money (opens in a new tab) हे संगणकीय कोडी सोडवून पैसे तयार करण्याची तसेच विकेंद्रित एकमताची कल्पना मांडणारा पहिला प्रस्ताव बनला, परंतु विकेंद्रित एकमत प्रत्यक्षात कसे लागू केले जाऊ शकते याबद्दल प्रस्तावात तपशीलांचा अभाव होता. 2005 मध्ये, हॅल फिनी यांनी "पुन्हा वापरण्यायोग्य प्रूफ-ऑफ-वर्क (opens in a new tab)" (reusable proofs of work) ची संकल्पना सादर केली, ही एक अशी प्रणाली आहे जी क्रिप्टोकरन्सीची संकल्पना तयार करण्यासाठी b-money मधील कल्पनांचा आणि ॲडम बॅकच्या संगणकीयदृष्ट्या कठीण Hashcash कोड्यांचा एकत्रित वापर करते, परंतु बॅकएंड म्हणून विश्वसनीय संगणनावर अवलंबून राहिल्यामुळे ती पुन्हा एकदा आदर्शापेक्षा कमी पडली. 2009 मध्ये, सातोशी नाकामोटो यांनी पहिल्यांदाच विकेंद्रित चलन प्रत्यक्षात आणले, ज्यामध्ये सार्वजनिक की गूढलेखनाद्वारे मालकी व्यवस्थापित करण्यासाठी स्थापित प्रिमिटिव्ह्ज आणि नाण्यांचा मालक कोण आहे याचा मागोवा ठेवण्यासाठी "प्रूफ-ऑफ-वर्क (PoW)" म्हणून ओळखल्या जाणाऱ्या एकमत अल्गोरिदमची सांगड घातली गेली.

प्रूफ-ऑफ-वर्क (PoW) मागील यंत्रणा या क्षेत्रातील एक मोठी प्रगती होती कारण तिने एकाच वेळी दोन समस्या सोडवल्या. प्रथम, याने एक सोपा आणि बऱ्यापैकी प्रभावी एकमत अल्गोरिदम प्रदान केला, ज्यामुळे नेटवर्कमधील नोड्सना बिटकॉइन लेजरच्या स्थितीच्या कॅनोनिकल अद्यतनांच्या संचावर एकत्रितपणे सहमत होण्याची परवानगी मिळाली. दुसरे म्हणजे, याने एकमत प्रक्रियेत मुक्त प्रवेश देण्याची यंत्रणा प्रदान केली, ज्यामुळे एकमतावर प्रभाव टाकण्याचा अधिकार कोणाला मिळतो हे ठरवण्याची राजकीय समस्या सुटली आणि त्याच वेळी सिबिल (sybil) हल्ल्यांना प्रतिबंध झाला. सहभागासाठी असलेल्या औपचारिक अडथळ्याच्या जागी (जसे की एखाद्या विशिष्ट सूचीवर अद्वितीय संस्था म्हणून नोंदणीकृत असण्याची आवश्यकता) आर्थिक अडथळा आणून हे साध्य केले जाते - एकमत मतदान प्रक्रियेतील एका नोडचे वजन हे त्या नोडने आणलेल्या संगणकीय शक्तीच्या थेट प्रमाणात असते. तेव्हापासून, प्रूफ-ऑफ-स्टेक (PoS) नावाचा एक पर्यायी दृष्टिकोन प्रस्तावित केला गेला आहे, ज्यामध्ये नोडचे वजन त्याच्या संगणकीय संसाधनांच्या नव्हे तर त्याच्याकडील चलनाच्या प्रमाणात मोजले जाते; या दोन दृष्टिकोनांच्या सापेक्ष गुणदोषांची चर्चा या पेपरच्या कक्षेबाहेर आहे परंतु हे लक्षात घेतले पाहिजे की दोन्ही दृष्टिकोन क्रिप्टोकरन्सीचा कणा म्हणून काम करण्यासाठी वापरले जाऊ शकतात.

स्थिती संक्रमण प्रणाली म्हणून बिटकॉइन

तांत्रिक दृष्टिकोनातून, बिटकॉइनसारख्या क्रिप्टोकरन्सीच्या लेजरचा विचार स्थिती संक्रमण प्रणाली (state transition system) म्हणून केला जाऊ शकतो, जिथे सर्व विद्यमान बिटकॉइन्सच्या मालकी स्थितीचा समावेश असलेली एक "स्थिती" असते आणि एक "स्थिती संक्रमण फंक्शन" असते जे एक स्थिती आणि एक व्यवहार घेते आणि परिणाम म्हणून नवीन स्थिती आउटपुट करते. उदाहरणार्थ, मानक बँकिंग प्रणालीमध्ये, स्थिती ही एक ताळेबंद (balance sheet) असते, व्यवहार ही A कडून B कडे $X हलवण्याची विनंती असते आणि स्थिती संक्रमण फंक्शन A च्या खात्यातील मूल्य $X ने कमी करते आणि B च्या खात्यातील मूल्य $X ने वाढवते. जर A च्या खात्यात मुळातच $X पेक्षा कमी रक्कम असेल, तर स्थिती संक्रमण फंक्शन त्रुटी (error) परत करते. म्हणून, आपण औपचारिकपणे असे परिभाषित करू शकतो:

APPLY(S,TX) -> S' किंवा ERROR

वर परिभाषित केलेल्या बँकिंग प्रणालीमध्ये:

APPLY({ Alice: $50, Bob: $50 },"send $20 from Alice to Bob") = { Alice: $30, Bob: $70 }

परंतु:

APPLY({ Alice: $50, Bob: $50 },"send $70 from Alice to Bob") = ERROR

बिटकॉइनमधील "स्थिती" म्हणजे तयार केलेल्या आणि अद्याप खर्च न केलेल्या सर्व नाण्यांचा (तांत्रिकदृष्ट्या, "खर्च न केलेले व्यवहार आउटपुट" किंवा UTXO) संग्रह आहे, ज्यामध्ये प्रत्येक UTXO चे एक मूल्य आणि एक मालक असतो (20-बाइट पत्त्याद्वारे परिभाषित केलेला जो मूलत: एक क्रिप्टोग्राफिक सार्वजनिक की असतो^fn1). एका व्यवहारामध्ये एक किंवा अधिक इनपुट असतात, ज्यामध्ये प्रत्येक इनपुटमध्ये विद्यमान UTXO चा संदर्भ आणि मालकाच्या पत्त्याशी संबंधित खाजगी की द्वारे तयार केलेली क्रिप्टोग्राफिक स्वाक्षरी असते, आणि एक किंवा अधिक आउटपुट असतात, ज्यामध्ये प्रत्येक आउटपुटमध्ये स्थितीत जोडला जाणारा नवीन UTXO असतो.

स्थिती संक्रमण फंक्शन APPLY(S,TX) -> S' ढोबळमानाने खालीलप्रमाणे परिभाषित केले जाऊ शकते:

1. TX मधील प्रत्येक इनपुटसाठी:

   • जर संदर्भित UTXO S मध्ये नसेल, तर त्रुटी परत करा.
   • जर प्रदान केलेली स्वाक्षरी UTXO च्या मालकाशी जुळत नसेल, तर त्रुटी परत करा.
2. जर सर्व इनपुट UTXO च्या मूल्यांची बेरीज सर्व आउटपुट UTXO च्या मूल्यांच्या बेरजेपेक्षा कमी असेल, तर त्रुटी परत करा.
3. सर्व इनपुट UTXO काढून टाकून आणि सर्व आउटपुट UTXO जोडून S परत करा.

पहिल्या पायरीचा पहिला भाग व्यवहार पाठवणाऱ्यांना अस्तित्वात नसलेली नाणी खर्च करण्यापासून प्रतिबंधित करतो, पहिल्या पायरीचा दुसरा भाग व्यवहार पाठवणाऱ्यांना इतर लोकांची नाणी खर्च करण्यापासून प्रतिबंधित करतो आणि दुसरी पायरी मूल्याचे संवर्धन लागू करते. पेमेंटसाठी याचा वापर करण्यासाठी, प्रोटोकॉल खालीलप्रमाणे आहे. समजा ॲलिसला बॉबला 11.7 BTC पाठवायचे आहेत. प्रथम, ॲलिस तिच्या मालकीच्या उपलब्ध UTXO चा संच शोधेल ज्याची बेरीज किमान 11.7 BTC असेल. वास्तविक पाहता, ॲलिसला नेमके 11.7 BTC मिळू शकणार नाहीत; समजा तिला मिळू शकणारी सर्वात लहान बेरीज 6+4+2=12 आहे. त्यानंतर ती त्या तीन इनपुट आणि दोन आउटपुटसह एक व्यवहार तयार करते. पहिले आउटपुट 11.7 BTC असेल ज्याचा मालक बॉबचा पत्ता असेल आणि दुसरे आउटपुट उर्वरित 0.3 BTC "सुट्टे" (change) असेल, ज्याची मालक स्वतः ॲलिस असेल.

खनन

जर आपल्याकडे विश्वासार्ह केंद्रीकृत सेवेचा प्रवेश असता, तर ही प्रणाली लागू करणे अगदी सोपे असते; स्थितीचा मागोवा ठेवण्यासाठी केंद्रीकृत सर्व्हरच्या हार्ड ड्राईव्हचा वापर करून, वर्णन केल्याप्रमाणेच ते सहजपणे कोड केले जाऊ शकले असते. तथापि, बिटकॉइनच्या बाबतीत आपण एक विकेंद्रित चलन प्रणाली तयार करण्याचा प्रयत्न करत आहोत, त्यामुळे व्यवहारांच्या क्रमावर सर्वांचे एकमत आहे याची खात्री करण्यासाठी आपल्याला स्थिती व्यवहार प्रणालीची एकमत प्रणालीशी सांगड घालावी लागेल. बिटकॉइनच्या विकेंद्रित एकमत प्रक्रियेसाठी नेटवर्कमधील नोड्सनी "ब्लॉक" नावाचे व्यवहारांचे पॅकेजेस तयार करण्याचा सतत प्रयत्न करणे आवश्यक आहे. नेटवर्कने दर दहा मिनिटांनी साधारणपणे एक ब्लॉक तयार करणे अपेक्षित आहे, ज्यामध्ये प्रत्येक ब्लॉकमध्ये टाइमस्टॅम्प, एक नॉन्स, मागील ब्लॉकचा संदर्भ (म्हणजेच हॅश) आणि मागील ब्लॉकपासून झालेल्या सर्व व्यवहारांची सूची असते. कालांतराने, यामुळे एक कायमस्वरूपी, सतत वाढणारी "ब्लॉकचेन" तयार होते जी बिटकॉइन लेजरची नवीनतम स्थिती दर्शवण्यासाठी सतत अद्यतनित होते.

एखादा ब्लॉक वैध आहे की नाही हे तपासण्यासाठीचा अल्गोरिदम, या पॅराडाइममध्ये व्यक्त केल्याप्रमाणे, खालीलप्रमाणे आहे:

1. ब्लॉकद्वारे संदर्भित केलेला मागील ब्लॉक अस्तित्वात आहे आणि वैध आहे का ते तपासा.
2. ब्लॉकचा टाइमस्टॅम्प मागील ब्लॉकच्या टाइमस्टॅम्पपेक्षा मोठा आहे^fn2 आणि भविष्यातील 2 तासांपेक्षा कमी आहे का ते तपासा.
3. ब्लॉकवरील प्रूफ-ऑफ-वर्क (PoW) वैध आहे का ते तपासा.
4. समजा S[0] ही मागील ब्लॉकच्या शेवटी असलेली स्थिती आहे.
5. समजा TX ही ब्लॉकची व्यवहार सूची आहे ज्यामध्ये n व्यवहार आहेत. 0...n-1 मधील सर्व i साठी, S[i+1] = APPLY(S[i],TX[i]) सेट करा. जर कोणत्याही ॲप्लिकेशनने त्रुटी परत केली, तर बाहेर पडा आणि false परत करा.
6. true परत करा, आणि या ब्लॉकच्या शेवटी असलेली स्थिती म्हणून S[n] ची नोंदणी करा.

थोडक्यात, ब्लॉकमधील प्रत्येक व्यवहाराने व्यवहार कार्यान्वित होण्यापूर्वीच्या कॅनोनिकल स्थितीपासून काही नवीन स्थितीपर्यंत वैध स्थिती संक्रमण प्रदान करणे आवश्यक आहे. लक्षात घ्या की स्थिती कोणत्याही प्रकारे ब्लॉकमध्ये एन्कोड केलेली नसते; हे केवळ प्रमाणीकरण करणाऱ्या नोडने लक्षात ठेवण्यासाठी एक ॲब्स्ट्रॅक्शन आहे आणि कोणत्याही ब्लॉकसाठी केवळ उत्पत्ती स्थितीपासून (genesis state) सुरुवात करून आणि प्रत्येक ब्लॉकमधील प्रत्येक व्यवहार क्रमाने लागू करून (सुरक्षितपणे) मोजले जाऊ शकते. याव्यतिरिक्त, हे लक्षात घ्या की मायनर ज्या क्रमाने ब्लॉकमध्ये व्यवहारांचा समावेश करतो तो क्रम महत्त्वाचा असतो; जर ब्लॉकमध्ये A आणि B असे दोन व्यवहार असतील जेथे B हा A ने तयार केलेला UTXO खर्च करत असेल, तर A हा B च्या आधी आल्यासच ब्लॉक वैध असेल, अन्यथा नाही.

वरील सूचीमध्ये उपस्थित असलेली एक वैधता अट जी इतर प्रणालींमध्ये आढळत नाही ती म्हणजे "प्रूफ-ऑफ-वर्क (PoW)" ची आवश्यकता. अचूक अट अशी आहे की प्रत्येक ब्लॉकचा डबल-SHA256 हॅश, जो 256-बिट संख्या मानला जातो, तो डायनॅमिकली ॲडजस्ट केलेल्या लक्ष्यापेक्षा कमी असला पाहिजे, जो हे लिहिण्याच्या वेळी अंदाजे 2¹⁸⁷ आहे. याचा उद्देश ब्लॉक निर्मिती संगणकीयदृष्ट्या "कठीण" बनवणे हा आहे, ज्यामुळे सिबिल हल्लेखोरांना संपूर्ण ब्लॉकचेन त्यांच्या बाजूने पुन्हा बनवण्यापासून रोखता येते. कारण SHA256 हे पूर्णपणे अप्रत्याशित स्यूडो-रँडम फंक्शन म्हणून डिझाइन केलेले आहे, वैध ब्लॉक तयार करण्याचा एकमेव मार्ग म्हणजे केवळ ट्रायल आणि एरर, वारंवार नॉन्स वाढवणे आणि नवीन हॅश जुळतो की नाही हे पाहणे.

~2¹⁸⁷ च्या सध्याच्या लक्ष्यावर, वैध ब्लॉक सापडण्यापूर्वी नेटवर्कला सरासरी ~2⁶⁹ प्रयत्न करावे लागतात; सर्वसाधारणपणे, नेटवर्कद्वारे दर 2016 ब्लॉक्सनंतर लक्ष्य पुन्हा कॅलिब्रेट केले जाते जेणेकरून सरासरी दर दहा मिनिटांनी नेटवर्कमधील काही नोडद्वारे नवीन ब्लॉक तयार केला जाईल. या संगणकीय कार्यासाठी मायनर्सना मोबदला देण्यासाठी, प्रत्येक ब्लॉकच्या मायनरला स्वतःला कुठूनही 25 BTC देणारा व्यवहार समाविष्ट करण्याचा अधिकार आहे. याव्यतिरिक्त, जर कोणत्याही व्यवहाराच्या आउटपुटपेक्षा त्याच्या इनपुटमध्ये एकूण मूल्य जास्त असेल, तर तो फरक देखील "व्यवहार शुल्क" म्हणून मायनरला जातो. विशेष म्हणजे, BTC जारी करण्याची ही एकमेव यंत्रणा आहे; उत्पत्ती स्थितीत (genesis state) कोणतीही नाणी नव्हती.

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

1. काही उत्पादनाच्या बदल्यात (शक्यतो जलद-वितरण होणारी डिजिटल वस्तू) व्यापाऱ्याला 100 BTC पाठवा
2. उत्पादनाच्या वितरणाची प्रतीक्षा करा
3. तेच 100 BTC स्वतःला पाठवणारा दुसरा व्यवहार तयार करा
4. स्वतःला केलेला व्यवहार हाच पहिला होता हे नेटवर्कला पटवून देण्याचा प्रयत्न करा.

एकदा पायरी (1) पूर्ण झाल्यानंतर, काही मिनिटांनंतर एखादा मायनर तो व्यवहार एका ब्लॉकमध्ये समाविष्ट करेल, समजा ब्लॉक क्रमांक 270000. सुमारे एका तासानंतर, त्या ब्लॉकनंतर चेनमध्ये आणखी पाच ब्लॉक्स जोडले गेले असतील, ज्यापैकी प्रत्येक ब्लॉक अप्रत्यक्षपणे त्या व्यवहाराकडे निर्देश करेल आणि अशा प्रकारे त्याची "पुष्टी" करेल. या टप्प्यावर, व्यापारी पेमेंट अंतिम झालेले म्हणून स्वीकारेल आणि उत्पादन वितरित करेल; आपण असे गृहीत धरत आहोत की ही एक डिजिटल वस्तू आहे, त्यामुळे वितरण त्वरित होते. आता, हल्लेखोर 100 BTC स्वतःला पाठवणारा दुसरा व्यवहार तयार करतो. जर हल्लेखोराने तो व्यवहार फक्त नेटवर्कमध्ये (in the wild) सोडला, तर त्यावर प्रक्रिया केली जाणार नाही; मायनर्स APPLY(S,TX) चालवण्याचा प्रयत्न करतील आणि त्यांच्या लक्षात येईल की TX असा UTXO वापरतो जो आता स्थितीत नाही. त्यामुळे त्याऐवजी, हल्लेखोर ब्लॉकचेनचा "फोर्क" तयार करतो, ज्याची सुरुवात ब्लॉक 270000 ची दुसरी आवृत्ती मायनिंग करून होते जी त्याच ब्लॉक 269999 ला मूळ (parent) म्हणून निर्देशित करते परंतु जुन्या व्यवहाराच्या जागी नवीन व्यवहार असतो. ब्लॉक डेटा वेगळा असल्यामुळे, यासाठी प्रूफ-ऑफ-वर्क (PoW) पुन्हा करणे आवश्यक आहे. शिवाय, हल्लेखोराच्या ब्लॉक 270000 च्या नवीन आवृत्तीचा हॅश वेगळा आहे, त्यामुळे मूळ ब्लॉक्स 270001 ते 270005 त्याकडे "निर्देश" करत नाहीत; अशा प्रकारे, मूळ चेन आणि हल्लेखोराची नवीन चेन पूर्णपणे वेगळी असते. नियम असा आहे की फोर्कमध्ये सर्वात लांब ब्लॉकचेन सत्य मानली जाते, आणि म्हणून कायदेशीर मायनर्स 270005 चेनवर काम करतील तर हल्लेखोर एकटाच 270000 चेनवर काम करत असेल. हल्लेखोराला त्याची ब्लॉकचेन सर्वात लांब बनवण्यासाठी, त्याला उर्वरित नेटवर्कच्या एकत्रित संगणकीय शक्तीपेक्षा जास्त संगणकीय शक्तीची आवश्यकता असेल जेणेकरून तो त्यांच्या बरोबरीला पोहोचू शकेल (म्हणून, "51% हल्ला").

मर्कल ट्री

डावीकडे: शाखेच्या वैधतेचा पुरावा देण्यासाठी मर्कल ट्रीमध्ये केवळ थोड्या संख्येने नोड्स सादर करणे पुरेसे आहे.

उजवीकडे: मर्कल ट्रीचा कोणताही भाग बदलण्याचा कोणताही प्रयत्न शेवटी चेनमध्ये कुठेतरी विसंगती निर्माण करेल.

बिटकॉइनचे एक महत्त्वाचे स्केलेबिलिटी वैशिष्ट्य म्हणजे ब्लॉक बहु-स्तरीय डेटा स्ट्रक्चरमध्ये संग्रहित केला जातो. ब्लॉकचा "हॅश" हा प्रत्यक्षात फक्त ब्लॉक हेडरचा हॅश असतो, जो साधारणपणे 200-बाइटचा डेटा असतो ज्यामध्ये टाइमस्टॅम्प, नॉन्स, मागील ब्लॉकचा हॅश आणि ब्लॉकमधील सर्व व्यवहार संग्रहित करणाऱ्या मर्कल ट्री नावाच्या डेटा स्ट्रक्चरचा रूट हॅश असतो. मर्कल ट्री हा बायनरी ट्रीचा एक प्रकार आहे, जो नोड्सच्या संचाने बनलेला असतो ज्यामध्ये ट्रीच्या तळाशी मोठ्या संख्येने लीफ नोड्स असतात ज्यात अंतर्निहित डेटा असतो, मध्यवर्ती नोड्सचा एक संच असतो जिथे प्रत्येक नोड त्याच्या दोन चिल्ड्रेनचा हॅश असतो आणि शेवटी एकच रूट नोड असतो, जो त्याच्या दोन चिल्ड्रेनच्या हॅशपासून तयार होतो आणि ट्रीचे "शीर्ष" (top) दर्शवतो. मर्कल ट्रीचा उद्देश ब्लॉकमधील डेटा टप्प्याटप्प्याने वितरित करण्याची परवानगी देणे हा आहे: एखादा नोड एका स्रोताकडून ब्लॉकचे फक्त हेडर डाउनलोड करू शकतो, दुसऱ्या स्रोताकडून त्यांच्याशी संबंधित ट्रीचा छोटा भाग डाउनलोड करू शकतो आणि तरीही सर्व डेटा योग्य असल्याची खात्री बाळगू शकतो. हे कार्य करण्याचे कारण असे आहे की हॅशेस वरच्या दिशेने प्रसारित होतात: जर एखाद्या दुर्भावनापूर्ण वापरकर्त्याने मर्कल ट्रीच्या तळाशी बनावट व्यवहार बदलण्याचा प्रयत्न केला, तर या बदलामुळे वरील नोडमध्ये बदल होईल आणि त्यानंतर त्यावरील नोडमध्ये बदल होईल, शेवटी ट्रीचे रूट आणि पर्यायाने ब्लॉकचा हॅश बदलेल, ज्यामुळे प्रोटोकॉल त्याची पूर्णपणे वेगळा ब्लॉक म्हणून नोंदणी करेल (जवळजवळ निश्चितपणे अवैध प्रूफ-ऑफ-वर्कसह).

मर्कल ट्री प्रोटोकॉल दीर्घकालीन टिकाऊपणासाठी निःसंशयपणे आवश्यक आहे. बिटकॉइन नेटवर्कमधील "पूर्ण नोड", जो प्रत्येक ब्लॉकची संपूर्ण माहिती संग्रहित करतो आणि त्यावर प्रक्रिया करतो, एप्रिल 2014 पर्यंत बिटकॉइन नेटवर्कमध्ये सुमारे 15 GB डिस्क स्पेस घेतो आणि दरमहा एका गिगाबाइटपेक्षा जास्त वेगाने वाढत आहे. सध्या, हे काही डेस्कटॉप संगणकांसाठी व्यवहार्य आहे आणि फोनसाठी नाही, आणि भविष्यात केवळ व्यवसाय आणि छंद जोपासणारेच यात सहभागी होऊ शकतील. "सिम्प्लिफाईड पेमेंट व्हेरिफिकेशन" (SPV) म्हणून ओळखला जाणारा प्रोटोकॉल "लाईट नोड" नावाच्या नोड्सच्या दुसऱ्या वर्गाला अस्तित्वात राहण्याची परवानगी देतो, जे ब्लॉक हेडर्स डाउनलोड करतात, ब्लॉक हेडर्सवरील प्रूफ-ऑफ-वर्क (PoW) सत्यापित करतात आणि नंतर केवळ त्यांच्याशी संबंधित व्यवहारांशी जोडलेल्या "शाखा" डाउनलोड करतात. यामुळे लाईट नोड्सना संपूर्ण ब्लॉकचेनचा केवळ एक अतिशय लहान भाग डाउनलोड करून कोणत्याही बिटकॉइन व्यवहाराची स्थिती आणि त्यांची सध्याची शिल्लक काय आहे हे सुरक्षिततेच्या मजबूत हमीसह निर्धारित करण्याची परवानगी मिळते.

पर्यायी ब्लॉकचेन ॲप्लिकेशन्स

अंतर्निहित ब्लॉकचेन कल्पना घेऊन ती इतर संकल्पनांना लागू करण्याच्या कल्पनेलाही मोठा इतिहास आहे. 2005 मध्ये, निक साबो यांनी "मालक अधिकारासह सुरक्षित मालमत्ता शीर्षके (opens in a new tab)" ही संकल्पना मांडली, हा एक दस्तऐवज आहे ज्यामध्ये "रेप्लिकेटेड डेटाबेस तंत्रज्ञानातील नवीन प्रगती" कोणत्या जमिनीचा मालक कोण आहे याची नोंदणी संग्रहित करण्यासाठी ब्लॉकचेन-आधारित प्रणालीला कशी अनुमती देईल याचे वर्णन केले आहे, ज्यामध्ये होमस्टेडिंग, ॲडव्हर्स पझेशन आणि जॉर्जियन जमीन कर यांसारख्या संकल्पनांचा समावेश असलेली एक विस्तृत फ्रेमवर्क तयार केली आहे. तथापि, दुर्दैवाने त्यावेळी कोणतीही प्रभावी रेप्लिकेटेड डेटाबेस प्रणाली उपलब्ध नव्हती आणि त्यामुळे हा प्रोटोकॉल प्रत्यक्षात कधीही लागू केला गेला नाही. तथापि, 2009 नंतर, एकदा बिटकॉइनचे विकेंद्रित एकमत विकसित झाल्यानंतर अनेक पर्यायी ॲप्लिकेशन्स वेगाने उदयास येऊ लागले.

• Namecoin - 2010 मध्ये तयार केलेले, Namecoin (opens in a new tab) चे वर्णन विकेंद्रित नाव नोंदणी डेटाबेस म्हणून उत्तम प्रकारे केले जाऊ शकते. Tor, बिटकॉइन आणि BitMessage सारख्या विकेंद्रित प्रोटोकॉलमध्ये, खाती ओळखण्याचा काही मार्ग असणे आवश्यक आहे जेणेकरून इतर लोक त्यांच्याशी संवाद साधू शकतील, परंतु सर्व विद्यमान उपायांमध्ये उपलब्ध असलेला एकमेव प्रकारचा आयडेंटिफायर म्हणजे 1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy सारखा स्यूडो-रँडम हॅश. आदर्शपणे, एखाद्याला "george" सारख्या नावाचे खाते असणे आवडेल. तथापि, समस्या अशी आहे की जर एखादी व्यक्ती "george" नावाचे खाते तयार करू शकत असेल तर दुसरी व्यक्ती देखील स्वतःसाठी "george" नोंदणी करण्यासाठी त्याच प्रक्रियेचा वापर करू शकते आणि त्यांची तोतयागिरी करू शकते. यावर एकमेव उपाय म्हणजे फर्स्ट-टू-फाईल पॅराडाइम, जिथे पहिला नोंदणीकर्ता यशस्वी होतो आणि दुसरा अयशस्वी होतो - ही समस्या बिटकॉइन एकमत प्रोटोकॉलसाठी अगदी योग्य आहे. Namecoin ही अशा कल्पनेचा वापर करून नाव नोंदणी प्रणालीची सर्वात जुनी आणि सर्वात यशस्वी अंमलबजावणी आहे.
• कलर्ड कॉइन्स (Colored coins) - कलर्ड कॉइन्स (opens in a new tab) चा उद्देश लोकांना त्यांची स्वतःची डिजिटल चलने तयार करण्याची परवानगी देणारा प्रोटोकॉल म्हणून काम करणे हा आहे - किंवा, एका युनिटच्या चलनासारख्या महत्त्वाच्या क्षुल्लक प्रकरणात, बिटकॉइन ब्लॉकचेनवर डिजिटल टोकन तयार करणे. कलर्ड कॉइन्स प्रोटोकॉलमध्ये, एखादी व्यक्ती विशिष्ट बिटकॉइन UTXO ला सार्वजनिकरित्या रंग नियुक्त करून नवीन चलन "जारी" करते आणि प्रोटोकॉल रिकर्सिव्हली इतर UTXO चा रंग तोच परिभाषित करतो जो त्यांना तयार करणाऱ्या व्यवहाराने खर्च केलेल्या इनपुटचा रंग असतो (मिश्र-रंगाच्या इनपुटच्या बाबतीत काही विशेष नियम लागू होतात). यामुळे वापरकर्त्यांना केवळ विशिष्ट रंगाचे UTXO असलेले वॉलेट्स राखता येतात आणि ते नियमित बिटकॉइन्सप्रमाणेच पाठवता येतात, त्यांना प्राप्त होणाऱ्या कोणत्याही UTXO चा रंग निर्धारित करण्यासाठी ब्लॉकचेनद्वारे बॅकट्रॅकिंग करता येते.
• मेटाकॉइन्स (Metacoins) - मेटाकॉइनमागील कल्पना अशी आहे की असा एक प्रोटोकॉल असावा जो बिटकॉइनच्या वर राहतो, मेटाकॉइन व्यवहार संग्रहित करण्यासाठी बिटकॉइन व्यवहारांचा वापर करतो परंतु त्याचे स्थिती संक्रमण फंक्शन वेगळे असते, APPLY'. कारण मेटाकॉइन प्रोटोकॉल अवैध मेटाकॉइन व्यवहारांना बिटकॉइन ब्लॉकचेनमध्ये दिसण्यापासून रोखू शकत नाही, एक नियम जोडला गेला आहे की जर APPLY'(S,TX) त्रुटी परत करत असेल, तर प्रोटोकॉल डीफॉल्टनुसार APPLY'(S,TX) = S वर जातो. हे एक अनियंत्रित क्रिप्टोकरन्सी प्रोटोकॉल तयार करण्यासाठी एक सोपी यंत्रणा प्रदान करते, ज्यामध्ये संभाव्यतः प्रगत वैशिष्ट्ये असू शकतात जी स्वतः बिटकॉइनमध्ये लागू केली जाऊ शकत नाहीत, परंतु विकासाचा खर्च खूप कमी असतो कारण खनन आणि नेटवर्किंगची गुंतागुंत आधीच बिटकॉइन प्रोटोकॉलद्वारे हाताळली जाते. मेटाकॉइन्सचा वापर आर्थिक कॉन्ट्रॅक्ट्सचे काही वर्ग, नाव नोंदणी आणि विकेंद्रित एक्सचेंज लागू करण्यासाठी केला गेला आहे.

अशा प्रकारे, सर्वसाधारणपणे, एकमत प्रोटोकॉल तयार करण्यासाठी दोन दृष्टिकोन आहेत: एक स्वतंत्र नेटवर्क तयार करणे आणि बिटकॉइनच्या वर एक प्रोटोकॉल तयार करणे. पहिला दृष्टिकोन, Namecoin सारख्या ॲप्लिकेशन्सच्या बाबतीत बऱ्यापैकी यशस्वी असला तरी, लागू करणे कठीण आहे; प्रत्येक वैयक्तिक अंमलबजावणीला स्वतंत्र ब्लॉकचेन बूटस्ट्रॅप करणे आवश्यक असते, तसेच सर्व आवश्यक स्थिती संक्रमण आणि नेटवर्किंग कोड तयार करणे आणि त्याची चाचणी करणे आवश्यक असते. याव्यतिरिक्त, आम्ही असा अंदाज वर्तवतो की विकेंद्रित एकमत तंत्रज्ञानासाठी ॲप्लिकेशन्सचा संच पॉवर लॉ डिस्ट्रिब्युशनचे अनुसरण करेल जिथे बहुसंख्य ॲप्लिकेशन्स स्वतःची ब्लॉकचेन असण्याइतके मोठे नसतील आणि आम्ही नोंद घेतो की विकेंद्रित ॲप्लिकेशन्सचे (dapp) मोठे वर्ग अस्तित्वात आहेत, विशेषतः विकेंद्रित स्वायत्त संस्था, ज्यांना एकमेकांशी संवाद साधण्याची आवश्यकता असते.

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

स्क्रिप्टिंग

कोणत्याही विस्ताराशिवाय, बिटकॉइन प्रोटोकॉल प्रत्यक्षात "स्मार्ट कॉन्ट्रॅक्ट" च्या संकल्पनेची कमकुवत आवृत्ती सुलभ करतो. बिटकॉइनमधील UTXO ची मालकी केवळ सार्वजनिक की कडेच नाही, तर साध्या स्टॅक-आधारित प्रोग्रामिंग भाषेत व्यक्त केलेल्या अधिक गुंतागुंतीच्या स्क्रिप्टकडे देखील असू शकते. या पॅराडाइममध्ये, तो UTXO खर्च करणाऱ्या व्यवहाराने स्क्रिप्टचे समाधान करणारा डेटा प्रदान करणे आवश्यक आहे. खरेतर, मूलभूत सार्वजनिक की मालकी यंत्रणा देखील स्क्रिप्टद्वारे लागू केली जाते: स्क्रिप्ट इनपुट म्हणून लंबवर्तुळाकार वक्र स्वाक्षरी घेते, व्यवहार आणि UTXO च्या मालकीच्या पत्त्यावर तिची पडताळणी करते आणि पडताळणी यशस्वी झाल्यास 1 आणि अन्यथा 0 परत करते. विविध अतिरिक्त वापर प्रकरणांसाठी इतर, अधिक गुंतागुंतीच्या स्क्रिप्ट्स अस्तित्वात आहेत. उदाहरणार्थ, एखादी व्यक्ती अशी स्क्रिप्ट तयार करू शकते ज्याला प्रमाणित करण्यासाठी दिलेल्या तीनपैकी दोन खाजगी की च्या स्वाक्षऱ्या आवश्यक असतात ("मल्टीसिग"), हा सेटअप कॉर्पोरेट खाती, सुरक्षित बचत खाती आणि काही मर्चंट एस्क्रो परिस्थितींसाठी उपयुक्त आहे. संगणकीय समस्यांच्या उपायांसाठी बक्षीस (bounties) देण्यासाठी देखील स्क्रिप्ट्सचा वापर केला जाऊ शकतो आणि एखादी व्यक्ती अशी स्क्रिप्ट देखील तयार करू शकते जी असे म्हणते की "जर तुम्ही मला या मूल्याचा Dogecoin व्यवहार पाठवल्याचा SPV पुरावा देऊ शकत असाल तर हा बिटकॉइन UTXO तुमचा आहे", जे मूलत: विकेंद्रित क्रॉस-क्रिप्टोकरन्सी एक्सचेंजला अनुमती देते.

तथापि, बिटकॉइनमध्ये लागू केलेल्या स्क्रिप्टिंग भाषेच्या अनेक महत्त्वाच्या मर्यादा आहेत:

• ट्युरिंग-कम्प्लिटनेसचा अभाव (Lack of Turing-completeness) - म्हणजेच, बिटकॉइन स्क्रिप्टिंग भाषा संगणनाच्या मोठ्या उपसंचाला समर्थन देत असली तरी, ती जवळजवळ प्रत्येक गोष्टीला समर्थन देत नाही. मुख्य श्रेणी जी गहाळ आहे ती म्हणजे लूप्स (loops). व्यवहार पडताळणी दरम्यान अनंत लूप्स टाळण्यासाठी हे केले जाते; सैद्धांतिकदृष्ट्या स्क्रिप्ट प्रोग्रामर्ससाठी हा एक पार करता येण्याजोगा अडथळा आहे, कारण कोणताही लूप if स्टेटमेंटसह अंतर्निहित कोड अनेक वेळा पुनरावृत्ती करून अनुकरण केला जाऊ शकतो, परंतु यामुळे अशा स्क्रिप्ट्स तयार होतात ज्या स्पेसच्या दृष्टीने अत्यंत अकार्यक्षम असतात. उदाहरणार्थ, पर्यायी लंबवर्तुळाकार वक्र स्वाक्षरी अल्गोरिदम लागू करण्यासाठी बहुधा 256 पुनरावृत्ती गुणाकार फेऱ्यांची आवश्यकता असेल ज्या सर्व वैयक्तिकरित्या कोडमध्ये समाविष्ट केल्या जातील.
• मूल्य-अंधत्व (Value-blindness) - UTXO स्क्रिप्टसाठी काढता येणाऱ्या रकमेवर सूक्ष्म नियंत्रण (fine-grained control) प्रदान करण्याचा कोणताही मार्ग नाही. उदाहरणार्थ, ओरॅकल कॉन्ट्रॅक्टचा एक शक्तिशाली वापर हेजिंग कॉन्ट्रॅक्ट असू शकतो, जिथे A आणि B $1000 किमतीचे BTC गुंतवतात आणि 30 दिवसांनंतर स्क्रिप्ट A ला $1000 किमतीचे BTC आणि उर्वरित B ला पाठवते. यासाठी USD मध्ये 1 BTC चे मूल्य निर्धारित करण्यासाठी ओरॅकलची आवश्यकता असेल, परंतु तरीही सध्या उपलब्ध असलेल्या पूर्णपणे केंद्रीकृत उपायांच्या तुलनेत विश्वास आणि पायाभूत सुविधांच्या आवश्यकतेच्या बाबतीत ही एक मोठी सुधारणा आहे. तथापि, UTXO हे सर्व-किंवा-काहीही-नाही (all-or-nothing) असल्यामुळे, हे साध्य करण्याचा एकमेव मार्ग म्हणजे वेगवेगळ्या मूल्यांचे अनेक UTXO असण्याचा अत्यंत अकार्यक्षम हॅक वापरणे (उदा. 30 पर्यंतच्या प्रत्येक k साठी 2^k चा एक UTXO) आणि ओरॅकलला A ला कोणता UTXO पाठवायचा आणि B ला कोणता हे निवडायला लावणे.
• स्थितीचा अभाव (Lack of state) - UTXO एकतर खर्च केले जाऊ शकतात किंवा खर्च न केलेले असू शकतात; बहु-स्तरीय कॉन्ट्रॅक्ट्स किंवा स्क्रिप्ट्ससाठी कोणतीही संधी नाही जी त्यापलीकडे कोणतीही इतर अंतर्गत स्थिती ठेवते. यामुळे बहु-स्तरीय ऑप्शन्स कॉन्ट्रॅक्ट्स, विकेंद्रित एक्सचेंज ऑफर्स किंवा द्वि-स्तरीय क्रिप्टोग्राफिक बांधिलकी प्रोटोकॉल (सुरक्षित संगणकीय बक्षिसांसाठी आवश्यक) बनवणे कठीण होते. याचा अर्थ असाही होतो की UTXO चा वापर केवळ साधे, एक-वेळचे कॉन्ट्रॅक्ट्स तयार करण्यासाठी केला जाऊ शकतो आणि विकेंद्रित संस्थांसारखे अधिक जटिल "स्टेटफुल" कॉन्ट्रॅक्ट्स तयार करण्यासाठी नाही, आणि यामुळे मेटा-प्रोटोकॉल लागू करणे कठीण होते. बायनरी स्थिती आणि मूल्य-अंधत्व यांचा एकत्रित अर्थ असाही होतो की आणखी एक महत्त्वाचा ॲप्लिकेशन, रक्कम काढण्याची मर्यादा (withdrawal limits), अशक्य आहे.
• ब्लॉकचेन-अंधत्व (Blockchain-blindness) - UTXO हे नॉन्स, टाइमस्टॅम्प आणि मागील ब्लॉक हॅश यांसारख्या ब्लॉकचेन डेटासाठी अंध असतात. हे स्क्रिप्टिंग भाषेला यादृच्छिकतेच्या संभाव्य मौल्यवान स्रोतापासून वंचित ठेवून जुगार आणि इतर अनेक श्रेणींमधील ॲप्लिकेशन्सना गंभीरपणे मर्यादित करते.

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

इथेरियम

इथेरियमचा उद्देश विकेंद्रित ॲप्लिकेशन्स (dapps) तयार करण्यासाठी एक पर्यायी प्रोटोकॉल तयार करणे हा आहे, जो तडजोडींचा एक वेगळा संच प्रदान करतो जो आम्हाला विश्वास आहे की विकेंद्रित ॲप्लिकेशन्सच्या मोठ्या वर्गासाठी खूप उपयुक्त ठरेल, विशेषत: अशा परिस्थितींवर भर देऊन जिथे जलद विकास वेळ, लहान आणि क्वचितच वापरल्या जाणाऱ्या ॲप्लिकेशन्ससाठी सुरक्षा आणि वेगवेगळ्या ॲप्लिकेशन्सची अत्यंत कार्यक्षमतेने संवाद साधण्याची क्षमता महत्त्वाची असते. इथेरियम हे मूलत: अंतिम अमूर्त पायाभूत स्तर तयार करून करते: अंगभूत ट्युरिंग-कंप्लीट प्रोग्रामिंग भाषेसह एक ब्लॉकचेन, ज्यामुळे कोणालाही स्मार्ट कॉन्ट्रॅक्ट्स आणि विकेंद्रित ॲप्लिकेशन्स लिहिण्याची परवानगी मिळते जिथे ते मालकी, व्यवहार स्वरूप आणि स्थिती संक्रमण कार्यांसाठी स्वतःचे अनियंत्रित नियम तयार करू शकतात. Namecoin ची एक साधी आवृत्ती कोडच्या दोन ओळींमध्ये लिहिली जाऊ शकते आणि चलने आणि प्रतिष्ठा प्रणाली यांसारखे इतर प्रोटोकॉल वीसपेक्षा कमी ओळींमध्ये तयार केले जाऊ शकतात. स्मार्ट कॉन्ट्रॅक्ट्स, क्रिप्टोग्राफिक "बॉक्सेस" ज्यामध्ये मूल्य असते आणि विशिष्ट अटी पूर्ण झाल्यावरच ते अनलॉक करतात, ते देखील प्लॅटफॉर्मवर तयार केले जाऊ शकतात, ज्यामध्ये ट्युरिंग-कंप्लीटनेस, मूल्य-जागरूकता, ब्लॉकचेन-जागरूकता आणि स्थिती यांच्या अतिरिक्त शक्तींमुळे बिटकॉइन स्क्रिप्टिंगद्वारे ऑफर केलेल्या शक्तीपेक्षा खूप जास्त शक्ती असते.

इथेरियम खाती

इथेरियममध्ये, स्थिती "खाती" नावाच्या ऑब्जेक्ट्सची बनलेली असते, ज्यामध्ये प्रत्येक खात्याचा 20-बाइट पत्ता असतो आणि स्थिती संक्रमणे ही खात्यांमधील मूल्य आणि माहितीचे थेट हस्तांतरण असतात. इथेरियम खात्यामध्ये चार फील्ड असतात:

• नॉन्स, प्रत्येक व्यवहार केवळ एकदाच प्रक्रियेत आणला जाऊ शकतो याची खात्री करण्यासाठी वापरला जाणारा काउंटर
• खात्याची सध्याची इथर शिल्लक
• खात्याचा कॉन्ट्रॅक्ट कोड, जर उपस्थित असेल
• खात्याचे स्टोरेज (डीफॉल्टनुसार रिक्त)

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

लक्षात घ्या की इथेरियममधील "कॉन्ट्रॅक्ट्स" कडे असे काहीतरी म्हणून पाहिले जाऊ नये जे "पूर्ण" केले पाहिजे किंवा "पालन" केले पाहिजे; त्याऐवजी, ते इथेरियम एक्झिक्यूशन वातावरणात राहणाऱ्या "स्वायत्त एजंट्स" सारखे आहेत, जे संदेश किंवा व्यवहाराद्वारे "प्रवृत्त" केल्यावर नेहमी कोडचा एक विशिष्ट भाग कार्यान्वित करतात आणि पर्सिस्टंट व्हेरिएबल्सचा मागोवा ठेवण्यासाठी त्यांच्या स्वतःच्या इथर शिल्लक आणि त्यांच्या स्वतःच्या की/व्हॅल्यू स्टोअरवर थेट नियंत्रण ठेवतात.

संदेश आणि व्यवहार

"व्यवहार" हा शब्द इथेरियममध्ये स्वाक्षरी केलेल्या डेटा पॅकेजचा संदर्भ देण्यासाठी वापरला जातो जो बाह्य मालकीच्या खात्यातून पाठवला जाणारा संदेश संचयित करतो. व्यवहारांमध्ये हे समाविष्ट असते:

• संदेश प्राप्तकर्ता
• प्रेषकाची ओळख पटवणारी स्वाक्षरी
• प्रेषकाकडून प्राप्तकर्त्याकडे हस्तांतरित करावयाची इथरची रक्कम
• एक पर्यायी डेटा फील्ड
• एक STARTGAS मूल्य, जे व्यवहार अंमलबजावणीला घेण्याची परवानगी असलेल्या जास्तीत जास्त संगणकीय चरणांची संख्या दर्शवते
• एक GASPRICE मूल्य, जे प्रेषक प्रति संगणकीय चरण भरत असलेले शुल्क दर्शवते

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

STARTGAS आणि GASPRICE फील्ड इथेरियमच्या अँटी-डिनिअल ऑफ सर्व्हिस मॉडेलसाठी महत्त्वपूर्ण आहेत. कोडमधील अपघाती किंवा प्रतिकूल अनंत लूप किंवा इतर संगणकीय अपव्यय टाळण्यासाठी, प्रत्येक व्यवहाराला तो कोड अंमलबजावणीचे किती संगणकीय चरण वापरू शकतो याची मर्यादा निश्चित करणे आवश्यक आहे. संगणनाचे मूलभूत एकक "गॅस" आहे; सहसा, एका संगणकीय चरणासाठी 1 गॅस खर्च येतो, परंतु काही ऑपरेशन्ससाठी जास्त प्रमाणात गॅस खर्च होतो कारण ते संगणकीयदृष्ट्या अधिक महाग असतात, किंवा स्थितीचा भाग म्हणून संचयित करणे आवश्यक असलेल्या डेटाचे प्रमाण वाढवतात. व्यवहार डेटामधील प्रत्येक बाइटसाठी 5 गॅसचे शुल्क देखील आहे. शुल्क प्रणालीचा उद्देश हल्लेखोराला संगणन, बँडविड्थ आणि स्टोरेजसह ते वापरत असलेल्या प्रत्येक संसाधनासाठी प्रमाणानुसार पैसे देण्यास भाग पाडणे हा आहे; म्हणून, नेटवर्कला यापैकी कोणत्याही संसाधनाचे जास्त प्रमाणात सेवन करण्यास प्रवृत्त करणाऱ्या कोणत्याही व्यवहाराचे गॅस शुल्क वाढीच्या अंदाजे प्रमाणात असणे आवश्यक आहे.

संदेश

कॉन्ट्रॅक्ट्समध्ये इतर कॉन्ट्रॅक्ट्सना "संदेश" पाठवण्याची क्षमता असते. संदेश हे आभासी ऑब्जेक्ट्स आहेत जे कधीही सीरियलाइज केले जात नाहीत आणि केवळ इथेरियम एक्झिक्यूशन वातावरणात अस्तित्वात असतात. संदेशामध्ये हे समाविष्ट असते:

• संदेशाचा प्रेषक (अव्यक्त)
• संदेश प्राप्तकर्ता
• संदेशासोबत हस्तांतरित करावयाची इथरची रक्कम
• एक पर्यायी डेटा फील्ड
• एक STARTGAS मूल्य

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

लक्षात घ्या की व्यवहार किंवा कॉन्ट्रॅक्टद्वारे नियुक्त केलेली गॅस मंजुरी त्या व्यवहाराद्वारे आणि सर्व उप-अंमलबजावणीद्वारे वापरल्या जाणाऱ्या एकूण गॅसला लागू होते. उदाहरणार्थ, जर बाह्य घटक A ने B ला 1000 गॅससह व्यवहार पाठवला, आणि B ने C ला संदेश पाठवण्यापूर्वी 600 गॅस वापरला, आणि C च्या अंतर्गत अंमलबजावणीने परत येण्यापूर्वी 300 गॅस वापरला, तर B गॅस संपण्यापूर्वी आणखी 100 गॅस खर्च करू शकतो.

इथेरियम स्थिती संक्रमण कार्य

इथेरियम स्थिती संक्रमण कार्य, APPLY(S,TX) -> S' खालीलप्रमाणे परिभाषित केले जाऊ शकते:

1. व्यवहार सुव्यवस्थित आहे का (म्हणजेच, मूल्यांची योग्य संख्या आहे), स्वाक्षरी वैध आहे का आणि नॉन्स प्रेषकाच्या खात्यातील नॉन्सशी जुळतो का ते तपासा. नसल्यास, त्रुटी परत करा.
2. व्यवहार शुल्क STARTGAS * GASPRICE म्हणून मोजा आणि स्वाक्षरीवरून पाठवण्याचा पत्ता निश्चित करा. प्रेषकाच्या खात्यातील शिल्लकमधून शुल्क वजा करा आणि प्रेषकाचा नॉन्स वाढवा. खर्च करण्यासाठी पुरेशी शिल्लक नसल्यास, त्रुटी परत करा.
3. GAS = STARTGAS सुरू करा, आणि व्यवहारातील बाइट्ससाठी पैसे देण्यासाठी प्रति बाइट गॅसचे ठराविक प्रमाण काढून घ्या.
4. प्रेषकाच्या खात्यातून प्राप्तकर्त्याच्या खात्यात व्यवहार मूल्य हस्तांतरित करा. प्राप्तकर्ता खाते अद्याप अस्तित्वात नसल्यास, ते तयार करा. प्राप्तकर्ता खाते कॉन्ट्रॅक्ट असल्यास, कॉन्ट्रॅक्टचा कोड पूर्ण होईपर्यंत किंवा अंमलबजावणीसाठी गॅस संपेपर्यंत चालवा.
5. प्रेषकाकडे पुरेसे पैसे नसल्यामुळे मूल्य हस्तांतरण अयशस्वी झाल्यास, किंवा कोड अंमलबजावणीसाठी गॅस संपल्यास, शुल्काच्या पेमेंट व्यतिरिक्त सर्व स्थिती बदल पूर्ववत करा आणि मायनरच्या खात्यात शुल्क जोडा.
6. अन्यथा, उर्वरित सर्व गॅससाठीचे शुल्क प्रेषकाला परत करा आणि वापरलेल्या गॅससाठी दिलेले शुल्क मायनरला पाठवा.

उदाहरणार्थ, समजा कॉन्ट्रॅक्टचा कोड असा आहे:

if !self.storage[calldataload(0)]:
  self.storage[calldataload(0)] = calldataload(32)

लक्षात घ्या की प्रत्यक्षात कॉन्ट्रॅक्ट कोड लो-लेव्हल EVM कोडमध्ये लिहिला जातो; हे उदाहरण स्पष्टतेसाठी आमच्या हाय-लेव्हल भाषांपैकी एक असलेल्या Serpent मध्ये लिहिले आहे आणि ते EVM कोडमध्ये संकलित केले जाऊ शकते. समजा कॉन्ट्रॅक्टचे स्टोरेज रिकामे सुरू होते, आणि 10 इथर मूल्य, 2000 गॅस, 0.001 इथर गॅसप्राईस आणि 64 बाइट्स डेटासह एक व्यवहार पाठवला जातो, ज्यामध्ये 0-31 बाइट्स 2 ही संख्या दर्शवतात आणि 32-63 बाइट्स CHARLIE^fn3 ही स्ट्रिंग दर्शवतात. या प्रकरणात स्थिती संक्रमण कार्याची प्रक्रिया खालीलप्रमाणे आहे:

1. व्यवहार वैध आणि सुव्यवस्थित आहे का ते तपासा.
2. व्यवहार प्रेषकाकडे किमान 2000 * 0.001 = 2 इथर आहेत का ते तपासा. जर असतील, तर प्रेषकाच्या खात्यातून 2 इथर वजा करा.
3. गॅस = 2000 सुरू करा; व्यवहार 170 बाइट्स लांब आहे आणि बाइट-शुल्क 5 आहे असे गृहीत धरून, 850 वजा करा जेणेकरून 1150 गॅस शिल्लक राहील.
4. प्रेषकाच्या खात्यातून आणखी 10 इथर वजा करा आणि ते कॉन्ट्रॅक्टच्या खात्यात जोडा.
5. कोड चालवा. या प्रकरणात, हे सोपे आहे: ते निर्देशांक 2 वरील कॉन्ट्रॅक्टचे स्टोरेज वापरले आहे का ते तपासते, ते नाही असे लक्षात येते आणि म्हणून ते निर्देशांक 2 वरील स्टोरेज CHARLIE मूल्यावर सेट करते. समजा यासाठी 187 गॅस लागतो, त्यामुळे गॅसची उर्वरित रक्कम 1150 - 187 = 963 आहे.
6. प्रेषकाच्या खात्यात 963 * 0.001 = 0.963 इथर परत जोडा आणि परिणामी स्थिती परत करा.

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

लक्षात घ्या की पूर्ववत करण्याच्या बाबतीत संदेश व्यवहारांसारखेच कार्य करतात: जर संदेशाच्या अंमलबजावणीसाठी गॅस संपला, तर त्या संदेशाची अंमलबजावणी आणि त्या अंमलबजावणीद्वारे ट्रिगर केलेल्या इतर सर्व अंमलबजावणी पूर्ववत होतात, परंतु मूळ अंमलबजावणी पूर्ववत करण्याची आवश्यकता नाही. याचा अर्थ असा की एका कॉन्ट्रॅक्टने दुसऱ्या कॉन्ट्रॅक्टला कॉल करणे "सुरक्षित" आहे, जसे की जर A ने B ला G गॅससह कॉल केला तर A च्या अंमलबजावणीमध्ये जास्तीत जास्त G गॅस गमावण्याची हमी असते. शेवटी, लक्षात घ्या की एक ऑपकोड आहे, CREATE, जो कॉन्ट्रॅक्ट तयार करतो; त्याचे अंमलबजावणी यांत्रिकी साधारणपणे CALL सारखेच असते, अपवाद वगळता की अंमलबजावणीचे आउटपुट नव्याने तयार केलेल्या कॉन्ट्रॅक्टचा कोड निर्धारित करते.

कोड अंमलबजावणी

इथेरियम कॉन्ट्रॅक्ट्समधील कोड लो-लेव्हल, स्टॅक-आधारित बाइटकोड भाषेत लिहिला जातो, ज्याला "इथेरियम व्हर्च्युअल मशीन कोड" किंवा "EVM कोड" असे म्हटले जाते. कोडमध्ये बाइट्सची मालिका असते, जिथे प्रत्येक बाइट एक ऑपरेशन दर्शवतो. सर्वसाधारणपणे, कोड अंमलबजावणी हा एक अनंत लूप असतो ज्यामध्ये वर्तमान प्रोग्राम काउंटरवर (जो शून्यापासून सुरू होतो) वारंवार ऑपरेशन करणे आणि नंतर प्रोग्राम काउंटर एकने वाढवणे समाविष्ट असते, जोपर्यंत कोडचा शेवट गाठला जात नाही किंवा त्रुटी किंवा STOP किंवा RETURN सूचना आढळत नाही. ऑपरेशन्सना डेटा संचयित करण्यासाठी तीन प्रकारच्या जागांमध्ये प्रवेश असतो:

• स्टॅक, एक लास्ट-इन-फर्स्ट-आउट कंटेनर ज्यामध्ये मूल्ये ढकलली आणि काढली जाऊ शकतात
• मेमरी, एक अमर्यादपणे विस्तारण्यायोग्य बाइट ॲरे
• कॉन्ट्रॅक्टचे दीर्घकालीन स्टोरेज, एक की/व्हॅल्यू स्टोअर. स्टॅक आणि मेमरीच्या विपरीत, जे संगणन संपल्यानंतर रीसेट होतात, स्टोरेज दीर्घकाळापर्यंत टिकून राहते.

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

EVM कोडचे औपचारिक अंमलबजावणी मॉडेल आश्चर्यकारकपणे सोपे आहे. इथेरियम व्हर्च्युअल मशीन चालू असताना, त्याची संपूर्ण संगणकीय स्थिती ट्यूपल (block_state, transaction, message, code, memory, stack, pc, gas) द्वारे परिभाषित केली जाऊ शकते, जिथे block_state ही सर्व खाती असलेली जागतिक स्थिती आहे आणि त्यात शिल्लक आणि स्टोरेज समाविष्ट आहे. अंमलबजावणीच्या प्रत्येक फेरीच्या सुरूवातीस, code चा pc वा बाइट (किंवा pc >= len(code) असल्यास 0) घेऊन वर्तमान सूचना शोधली जाते आणि प्रत्येक सूचनेची स्वतःची व्याख्या असते की ती ट्यूपलवर कसा परिणाम करते. उदाहरणार्थ, ADD स्टॅकमधून दोन आयटम काढते आणि त्यांची बेरीज ढकलते, gas 1 ने कमी करते आणि pc 1 ने वाढवते, आणि SSTORE स्टॅकमधून वरचे दोन आयटम काढते आणि दुसरा आयटम पहिल्या आयटमद्वारे निर्दिष्ट केलेल्या निर्देशांकावर कॉन्ट्रॅक्टच्या स्टोरेजमध्ये समाविष्ट करते. जरी जस्ट-इन-टाइम संकलनाद्वारे इथेरियम व्हर्च्युअल मशीन अंमलबजावणी ऑप्टिमाइझ करण्याचे अनेक मार्ग असले तरी, इथेरियमची मूलभूत अंमलबजावणी काहीशे ओळींच्या कोडमध्ये केली जाऊ शकते.

ब्लॉकचेन आणि खनन

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

1. संदर्भित मागील ब्लॉक अस्तित्वात आहे आणि वैध आहे का ते तपासा.
2. ब्लॉकचा टाइमस्टॅम्प संदर्भित मागील ब्लॉकपेक्षा जास्त आहे आणि भविष्यात 15 मिनिटांपेक्षा कमी आहे का ते तपासा.
3. ब्लॉक क्रमांक, काठिण्य, व्यवहार रूट, अंकल रूट आणि गॅस मर्यादा (विविध लो-लेव्हल इथेरियम-विशिष्ट संकल्पना) वैध आहेत का ते तपासा.
4. ब्लॉकमधील प्रूफ-ऑफ-वर्क (PoW) वैध आहे का ते तपासा.
5. S[0] ही मागील ब्लॉकच्या शेवटी असलेली स्थिती असू द्या.
6. TX ही ब्लॉकची व्यवहार सूची असू द्या, ज्यामध्ये n व्यवहार आहेत. 0...n-1 मधील सर्व i साठी, S[i+1] = APPLY(S[i],TX[i]) सेट करा. जर कोणत्याही ॲप्लिकेशन्सने त्रुटी परत केली, किंवा या टप्प्यापर्यंत ब्लॉकमध्ये वापरलेला एकूण गॅस GASLIMIT पेक्षा जास्त असेल, तर त्रुटी परत करा.
7. S_FINAL हे S[n] असू द्या, परंतु मायनरला दिलेले ब्लॉक बक्षीस जोडून.
8. स्थिती S_FINAL चे मर्कल ट्री रूट ब्लॉक हेडरमध्ये प्रदान केलेल्या अंतिम स्थिती रूटच्या समान आहे का ते तपासा. जर ते असेल, तर ब्लॉक वैध आहे; अन्यथा, तो वैध नाही.

हा दृष्टिकोन पहिल्या दृष्टीक्षेपात अत्यंत अकार्यक्षम वाटू शकतो, कारण त्याला प्रत्येक ब्लॉकसह संपूर्ण स्थिती संचयित करण्याची आवश्यकता असते, परंतु प्रत्यक्षात कार्यक्षमता बिटकॉइनच्या तुलनेत असावी. याचे कारण असे की स्थिती ट्री स्ट्रक्चरमध्ये संचयित केली जाते आणि प्रत्येक ब्लॉकनंतर ट्रीचा फक्त एक छोटा भाग बदलण्याची आवश्यकता असते. अशा प्रकारे, सर्वसाधारणपणे, दोन लगतच्या ब्लॉक्समध्ये ट्रीचा बहुतांश भाग समान असावा आणि म्हणून डेटा एकदा संचयित केला जाऊ शकतो आणि पॉइंटर्स (म्हणजेच, सबट्रीजचे हॅश) वापरून दोनदा संदर्भित केला जाऊ शकतो. हे साध्य करण्यासाठी "पॅट्रिशिया ट्री" म्हणून ओळखल्या जाणाऱ्या एका विशेष प्रकारच्या ट्रीचा वापर केला जातो, ज्यामध्ये मर्कल ट्री संकल्पनेतील बदलाचा समावेश आहे ज्यामुळे नोड्स केवळ बदललेच जात नाहीत तर कार्यक्षमतेने समाविष्ट आणि हटवले जाऊ शकतात. याव्यतिरिक्त, सर्व स्थिती माहिती शेवटच्या ब्लॉकचा भाग असल्यामुळे, संपूर्ण ब्लॉकचेन इतिहास संचयित करण्याची आवश्यकता नाही - एक धोरण जे, जर ते बिटकॉइनवर लागू केले जाऊ शकले, तर जागेत 5-20 पट बचत प्रदान करण्यासाठी मोजले जाऊ शकते.

भौतिक हार्डवेअरच्या संदर्भात, कॉन्ट्रॅक्ट कोड "कुठे" कार्यान्वित केला जातो हा एक सामान्यपणे विचारला जाणारा प्रश्न आहे. याचे एक सोपे उत्तर आहे: कॉन्ट्रॅक्ट कोड कार्यान्वित करण्याची प्रक्रिया ही स्थिती संक्रमण कार्याच्या व्याख्येचा भाग आहे, जी ब्लॉक प्रमाणीकरण अल्गोरिदमचा भाग आहे, त्यामुळे जर एखादा व्यवहार ब्लॉक B मध्ये जोडला गेला तर त्या व्यवहाराद्वारे निर्माण झालेली कोड अंमलबजावणी सर्व नोड्सद्वारे कार्यान्वित केली जाईल, आता आणि भविष्यात, जे ब्लॉक B डाउनलोड आणि प्रमाणित करतात.

ॲप्लिकेशन्स

साधारणपणे, इथेरियमवर तीन प्रकारची ॲप्लिकेशन्स असतात. पहिली श्रेणी आर्थिक ॲप्लिकेशन्सची आहे, जी वापरकर्त्यांना त्यांचे पैसे वापरून व्यवस्थापन करण्याचे आणि कॉन्ट्रॅक्ट्समध्ये प्रवेश करण्याचे अधिक शक्तिशाली मार्ग प्रदान करते. यामध्ये उप-चलन (sub-currencies), आर्थिक डेरिव्हेटिव्ह्ज, हेजिंग कॉन्ट्रॅक्ट्स, बचत वॉलेट्स, मृत्युपत्रे आणि शेवटी पूर्ण-प्रमाणातील रोजगार कॉन्ट्रॅक्ट्सच्या काही वर्गांचाही समावेश होतो. दुसरी श्रेणी अर्ध-आर्थिक ॲप्लिकेशन्सची आहे, जिथे पैशांचा सहभाग असतो परंतु जे केले जात आहे त्याची एक मोठी गैर-आर्थिक बाजू देखील असते; संगणकीय समस्यांच्या उपायांसाठी स्वयं-अंमलबजावणी करणारी बक्षिसे (self-enforcing bounties) हे याचे एक उत्तम उदाहरण आहे. शेवटी, ऑनलाइन मतदान आणि विकेंद्रित प्रशासन यांसारखी ॲप्लिकेशन्स आहेत जी अजिबात आर्थिक नाहीत.

टोकन प्रणाली

ऑन-ब्लॉकचेन टोकन प्रणालींचे अनेक उपयोग आहेत, जसे की USD किंवा सोन्यासारख्या मालमत्तेचे प्रतिनिधित्व करणारी उप-चलने, कंपनीचे शेअर्स, स्मार्ट मालमत्तेचे प्रतिनिधित्व करणारी वैयक्तिक टोकन्स, सुरक्षित आणि बनावट न करता येणारी कूपन्स, आणि अगदी पारंपारिक मूल्याशी कोणताही संबंध नसलेली टोकन प्रणाली, जी प्रोत्साहनासाठी पॉइंट प्रणाली म्हणून वापरली जाते. इथेरियममध्ये टोकन प्रणाली लागू करणे आश्चर्यकारकपणे सोपे आहे. येथे समजून घेण्याचा मुख्य मुद्दा हा आहे की चलन किंवा टोकन प्रणाली मूलत: एक डेटाबेस आहे ज्यामध्ये एकच क्रिया असते: A मधून X युनिट्स वजा करा आणि B ला X युनिट्स द्या, या अटीवर की (i) व्यवहारापूर्वी A कडे किमान X युनिट्स होते आणि (2) व्यवहाराला A ने मान्यता दिली आहे. टोकन प्रणाली लागू करण्यासाठी फक्त हे लॉजिक एका कॉन्ट्रॅक्टमध्ये लागू करणे आवश्यक आहे.

Serpent मध्ये टोकन प्रणाली लागू करण्यासाठीचा मूळ कोड खालीलप्रमाणे दिसतो:

def send(to, value):
  if self.storage[msg.sender] >= value:
    self.storage[msg.sender] = self.storage[msg.sender] - value
    self.storage[to] = self.storage[to] + value

हे मूलत: या दस्तऐवजात वर वर्णन केलेल्या "बँकिंग प्रणाली" स्थिती संक्रमण कार्याची (state transition function) शब्दशः अंमलबजावणी आहे. सुरुवातीला चलन युनिट्स वितरित करण्याच्या प्राथमिक पायरीसाठी आणि इतर काही विशिष्ट प्रकरणांसाठी (edge cases) कोडच्या काही अतिरिक्त ओळी जोडणे आवश्यक आहे, आणि आदर्शपणे इतर कॉन्ट्रॅक्ट्सना पत्त्याच्या शिल्लक रकमेची चौकशी करू देण्यासाठी एक फंक्शन जोडले जावे. पण यात एवढेच आहे. सैद्धांतिकदृष्ट्या, उप-चलन म्हणून काम करणाऱ्या इथेरियम-आधारित टोकन प्रणालींमध्ये आणखी एक महत्त्वाचे वैशिष्ट्य असू शकते जे ऑनचेन बिटकॉइन-आधारित मेटा-चलनांमध्ये नाही: थेट त्याच चलनात व्यवहार शुल्क भरण्याची क्षमता. हे अशा प्रकारे लागू केले जाईल की कॉन्ट्रॅक्ट एक इथर शिल्लक राखेल ज्याद्वारे ते पाठवणाऱ्याला शुल्क भरण्यासाठी वापरलेले इथर परत करेल, आणि ते शुल्काच्या रूपात घेतलेले अंतर्गत चलन युनिट्स गोळा करून आणि सतत चालणाऱ्या लिलावात त्यांची पुनर्विक्री करून ही शिल्लक पुन्हा भरेल. अशा प्रकारे वापरकर्त्यांना त्यांचे खाते इथरसह "सक्रिय" करावे लागेल, परंतु एकदा इथर जमा झाल्यावर ते पुन्हा वापरण्यायोग्य असेल कारण कॉन्ट्रॅक्ट प्रत्येक वेळी ते परत करेल.

आर्थिक डेरिव्हेटिव्ह्ज आणि स्थिर-मूल्य चलने

आर्थिक डेरिव्हेटिव्ह्ज हे "स्मार्ट कॉन्ट्रॅक्ट" चे सर्वात सामान्य ॲप्लिकेशन आहे आणि कोडमध्ये लागू करण्यासाठी सर्वात सोप्या गोष्टींपैकी एक आहे. आर्थिक कॉन्ट्रॅक्ट्स लागू करण्यात मुख्य आव्हान हे आहे की त्यापैकी बहुतेकांना बाह्य किंमत टिकरचा संदर्भ आवश्यक असतो; उदाहरणार्थ, एक अतिशय इष्ट ॲप्लिकेशन म्हणजे एक स्मार्ट कॉन्ट्रॅक्ट जे यूएस डॉलरच्या तुलनेत इथरच्या (किंवा इतर क्रिप्टोकरन्सीच्या) अस्थिरतेपासून संरक्षण (hedge) करते, परंतु असे करण्यासाठी कॉन्ट्रॅक्टला ETH/USD चे मूल्य काय आहे हे माहित असणे आवश्यक आहे. हे करण्याचा सर्वात सोपा मार्ग म्हणजे एका विशिष्ट पक्षाद्वारे (उदा. NASDAQ) राखलेल्या "डेटा फीड" कॉन्ट्रॅक्टद्वारे, जे अशा प्रकारे डिझाइन केलेले असते की त्या पक्षाला आवश्यकतेनुसार कॉन्ट्रॅक्ट अपडेट करण्याची क्षमता असते, आणि एक इंटरफेस प्रदान करते जो इतर कॉन्ट्रॅक्ट्सना त्या कॉन्ट्रॅक्टला संदेश पाठविण्याची आणि किंमत प्रदान करणारा प्रतिसाद परत मिळविण्याची परवानगी देतो.

तो महत्त्वपूर्ण घटक लक्षात घेता, हेजिंग कॉन्ट्रॅक्ट खालीलप्रमाणे दिसेल:

1. पक्ष A ने 1000 इथर इनपुट करण्याची प्रतीक्षा करा.
2. पक्ष B ने 1000 इथर इनपुट करण्याची प्रतीक्षा करा.
3. डेटा फीड कॉन्ट्रॅक्टला विचारणा करून मोजलेले 1000 इथरचे USD मूल्य स्टोरेजमध्ये नोंदवा, समजा हे $x आहे.
4. 30 दिवसांनंतर, A ला $x किमतीचे इथर (नवीन किंमत मिळवण्यासाठी डेटा फीड कॉन्ट्रॅक्टला पुन्हा विचारणा करून मोजलेले) आणि उर्वरित B ला पाठवण्यासाठी A किंवा B ला कॉन्ट्रॅक्ट "पुन्हा सक्रिय" करण्याची परवानगी द्या.

अशा कॉन्ट्रॅक्टमध्ये क्रिप्टो-कॉमर्समध्ये लक्षणीय क्षमता असेल. क्रिप्टोकरन्सीबद्दल सांगितलेली एक मुख्य समस्या म्हणजे ती अस्थिर आहे; जरी अनेक वापरकर्ते आणि व्यापाऱ्यांना क्रिप्टोग्राफिक मालमत्तेशी व्यवहार करण्याची सुरक्षितता आणि सोय हवी असली, तरी त्यांना एकाच दिवसात त्यांच्या निधीचे 23% मूल्य गमावण्याच्या शक्यतेला सामोरे जाण्याची इच्छा नसू शकते. आतापर्यंत, सर्वात सामान्यपणे प्रस्तावित केलेला उपाय म्हणजे जारीकर्त्या-समर्थित (issuer-backed) मालमत्ता; कल्पना अशी आहे की जारीकर्ता एक उप-चलन तयार करतो ज्यामध्ये त्यांना युनिट्स जारी करण्याचा आणि रद्द करण्याचा अधिकार असतो, आणि जो कोणी त्यांना (ऑफलाइन) निर्दिष्ट अंतर्निहित मालमत्तेचे (उदा. सोने, USD) एक युनिट प्रदान करतो त्याला चलनाचे एक युनिट प्रदान करतो. त्यानंतर जारीकर्ता जो कोणी क्रिप्टो-मालमत्तेचे एक युनिट परत पाठवतो त्याला अंतर्निहित मालमत्तेचे एक युनिट प्रदान करण्याचे वचन देतो. ही यंत्रणा कोणत्याही गैर-क्रिप्टोग्राफिक मालमत्तेला क्रिप्टोग्राफिक मालमत्तेमध्ये "उन्नत" (uplift) करण्याची परवानगी देते, बशर्ते जारीकर्त्यावर विश्वास ठेवता येईल.

प्रत्यक्षात मात्र, जारीकर्ते नेहमीच विश्वासार्ह नसतात आणि काही प्रकरणांमध्ये अशा सेवा अस्तित्वात येण्यासाठी बँकिंग पायाभूत सुविधा खूप कमकुवत किंवा खूप प्रतिकूल असतात. आर्थिक डेरिव्हेटिव्ह्ज एक पर्याय प्रदान करतात. येथे, मालमत्तेला पाठबळ देण्यासाठी निधी प्रदान करणाऱ्या एकाच जारीकर्त्याऐवजी, क्रिप्टोग्राफिक संदर्भ मालमत्तेची (उदा. ETH) किंमत वाढेल अशी पैज लावणारी सट्टेबाजांची विकेंद्रित बाजारपेठ ती भूमिका बजावते. जारीकर्त्यांच्या विपरीत, सट्टेबाजांकडे कराराच्या त्यांच्या बाजूने कसूर करण्याचा कोणताही पर्याय नसतो कारण हेजिंग कॉन्ट्रॅक्ट त्यांचा निधी एस्क्रोमध्ये (escrow) ठेवते. लक्षात घ्या की हा दृष्टिकोन पूर्णपणे विकेंद्रित नाही, कारण किंमत टिकर प्रदान करण्यासाठी अद्याप एका विश्वासार्ह स्रोताची आवश्यकता आहे, जरी पायाभूत सुविधांच्या आवश्यकता कमी करण्याच्या दृष्टीने (जारीकर्ता असण्यासारखे नाही, किंमत फीड जारी करण्यासाठी कोणत्याही परवान्यांची आवश्यकता नाही आणि बहुधा त्याचे मुक्त भाषण म्हणून वर्गीकरण केले जाऊ शकते) आणि फसवणुकीची शक्यता कमी करण्याच्या दृष्टीने ही एक मोठी सुधारणा आहे.

ओळख आणि प्रतिष्ठा प्रणाली

सर्वात जुनी पर्यायी क्रिप्टोकरन्सी, Namecoin (opens in a new tab) ने नाव नोंदणी प्रणाली प्रदान करण्यासाठी बिटकॉइन-सारखी ब्लॉकचेन वापरण्याचा प्रयत्न केला, जिथे वापरकर्ते इतर डेटासह सार्वजनिक डेटाबेसमध्ये त्यांची नावे नोंदवू शकतात. याचा मुख्य उपयोग DNS (opens in a new tab) प्रणालीसाठी सांगितला जातो, जो "bitcoin.org" (किंवा, Namecoin च्या बाबतीत, "bitcoin.bit") सारख्या डोमेन नावांना IP पत्त्याशी जोडतो. इतर उपयोगांमध्ये ईमेल प्रमाणीकरण आणि संभाव्यतः अधिक प्रगत प्रतिष्ठा प्रणालींचा समावेश आहे. इथेरियमवर Namecoin-सारखी नाव नोंदणी प्रणाली प्रदान करण्यासाठीचे मूळ कॉन्ट्रॅक्ट येथे आहे:

def register(name, value):
  if !self.storage[name]:
    self.storage[name] = value

हे कॉन्ट्रॅक्ट अतिशय सोपे आहे; हे इथेरियम नेटवर्कमधील फक्त एक डेटाबेस आहे ज्यामध्ये भर घालता येते, परंतु त्यातून काहीही बदलता किंवा काढता येत नाही. कोणतीही व्यक्ती काही मूल्यासह नाव नोंदवू शकते आणि ती नोंदणी कायमस्वरूपी राहते. अधिक प्रगत नाव नोंदणी कॉन्ट्रॅक्टमध्ये एक "फंक्शन क्लॉज" देखील असेल जो इतर कॉन्ट्रॅक्ट्सना त्याची चौकशी करण्याची परवानगी देईल, तसेच नावाच्या "मालकाला" (म्हणजेच, पहिल्या नोंदणीकर्त्याला) डेटा बदलण्यासाठी किंवा मालकी हस्तांतरित करण्यासाठी एक यंत्रणा असेल. यावर प्रतिष्ठा आणि वेब-ऑफ-ट्रस्ट कार्यक्षमता देखील जोडता येऊ शकते.

विकेंद्रित फाइल स्टोरेज

गेल्या काही वर्षांत, अनेक लोकप्रिय ऑनलाइन फाइल स्टोरेज स्टार्टअप्स उदयास आले आहेत, ज्यामध्ये ड्रॉपबॉक्स (Dropbox) सर्वात प्रमुख आहे, जे वापरकर्त्यांना त्यांच्या हार्ड ड्राइव्हचा बॅकअप अपलोड करण्याची परवानगी देतात आणि मासिक शुल्काच्या बदल्यात सेवा तो बॅकअप संचयित करते आणि वापरकर्त्याला त्यात प्रवेश करण्याची परवानगी देते. तथापि, या टप्प्यावर फाइल स्टोरेज मार्केट काही वेळा तुलनेने अकार्यक्षम असते; विविध विद्यमान उपायांवर एक नजर टाकल्यास असे दिसून येते की, विशेषतः "अनकॅनी व्हॅली" (uncanny valley) 20-200 GB स्तरावर जिथे मोफत कोटा किंवा एंटरप्राइझ-स्तरीय सवलती लागू होत नाहीत, मुख्य प्रवाहातील फाइल स्टोरेज खर्चाच्या मासिक किमती अशा आहेत की तुम्ही एकाच महिन्यात संपूर्ण हार्ड ड्राइव्हच्या किमतीपेक्षा जास्त पैसे देत आहात. इथेरियम कॉन्ट्रॅक्ट्स विकेंद्रित फाइल स्टोरेज इकोसिस्टमच्या विकासास अनुमती देऊ शकतात, जिथे वैयक्तिक वापरकर्ते त्यांच्या स्वतःच्या हार्ड ड्राइव्ह भाड्याने देऊन थोडे पैसे कमवू शकतात आणि न वापरलेली जागा फाइल स्टोरेजचा खर्च आणखी कमी करण्यासाठी वापरली जाऊ शकते.

अशा उपकरणाचा मुख्य आधारस्तंभ म्हणजे ज्याला आपण "विकेंद्रित ड्रॉपबॉक्स कॉन्ट्रॅक्ट" म्हणतो तो असेल. हे कॉन्ट्रॅक्ट खालीलप्रमाणे काम करते. प्रथम, इच्छित डेटा ब्लॉक्समध्ये विभागला जातो, गोपनीयतेसाठी प्रत्येक ब्लॉक एन्क्रिप्ट केला जातो आणि त्यातून एक मर्कल ट्री तयार केली जाते. त्यानंतर एक कॉन्ट्रॅक्ट बनवले जाते ज्यामध्ये असा नियम असतो की, प्रत्येक N ब्लॉक्सनंतर, कॉन्ट्रॅक्ट मर्कल ट्री मधील एक यादृच्छिक निर्देशांक (random index) निवडेल (मागील ब्लॉक हॅश वापरून, जो कॉन्ट्रॅक्ट कोडमधून प्रवेश करण्यायोग्य आहे, यादृच्छिकतेचा स्रोत म्हणून), आणि ट्रीमधील त्या विशिष्ट निर्देशांकावरील ब्लॉकच्या मालकीचा सरलीकृत पेमेंट पडताळणी-सारखा पुरावा असलेल्या व्यवहाराचा पुरवठा करणाऱ्या पहिल्या घटकाला X इथर देईल. जेव्हा एखाद्या वापरकर्त्याला त्यांची फाइल पुन्हा डाउनलोड करायची असते, तेव्हा ते फाइल पुनर्प्राप्त करण्यासाठी मायक्रोपेमेंट चॅनेल प्रोटोकॉल वापरू शकतात (उदा. प्रति 32 किलोबाइट्स 1 साबो द्या); सर्वात शुल्क-कार्यक्षम दृष्टिकोन असा आहे की पैसे देणाऱ्याने शेवटपर्यंत व्यवहार प्रकाशित करू नये, त्याऐवजी प्रत्येक 32 किलोबाइट्सनंतर त्याच नॉन्ससह थोड्या अधिक फायदेशीर व्यवहाराने तो बदलत राहावा.

प्रोटोकॉलचे एक महत्त्वाचे वैशिष्ट्य म्हणजे, जरी असे वाटत असले की आपण फाइल विसरण्याचा निर्णय न घेण्यासाठी अनेक यादृच्छिक नोड्सवर विश्वास ठेवत आहोत, तरीही गुप्त शेअरिंगद्वारे (secret sharing) फाइलचे अनेक तुकडे करून आणि प्रत्येक तुकडा अद्याप काही नोडच्या ताब्यात आहे हे पाहण्यासाठी कॉन्ट्रॅक्ट्सवर लक्ष ठेवून तो धोका शून्याच्या जवळपास कमी करता येतो. जर एखादे कॉन्ट्रॅक्ट अद्याप पैसे देत असेल, तर तो एक क्रिप्टोग्राफिक पुरावा प्रदान करतो की कोणीतरी अद्याप ती फाइल संचयित करत आहे.

विकेंद्रित स्वायत्त संस्था

"विकेंद्रित स्वायत्त संस्था" (decentralized autonomous organization) ची सामान्य संकल्पना एका आभासी घटकाची आहे ज्यामध्ये सदस्य किंवा भागधारकांचा एक विशिष्ट संच असतो ज्यांना, कदाचित 67% बहुमताने, घटकाचा निधी खर्च करण्याचा आणि त्याचा कोड सुधारण्याचा अधिकार असतो. संस्थेने आपला निधी कसा वाटप करावा हे सदस्य एकत्रितपणे ठरवतील. DAO चा निधी वाटप करण्याच्या पद्धतींमध्ये बक्षिसे, पगार यापासून ते कामाला बक्षीस देण्यासाठी अंतर्गत चलनासारख्या अधिक नाविन्यपूर्ण यंत्रणांचा समावेश असू शकतो. हे मूलत: पारंपारिक कंपनी किंवा ना-नफा संस्थेच्या कायदेशीर चौकटीची प्रतिकृती बनवते परंतु अंमलबजावणीसाठी केवळ क्रिप्टोग्राफिक ब्लॉकचेन तंत्रज्ञान वापरते. आतापर्यंत DAO च्या आसपासची बरीच चर्चा लाभांश मिळवणारे भागधारक आणि व्यापार करण्यायोग्य शेअर्स असलेल्या "विकेंद्रित स्वायत्त कॉर्पोरेशन" (DAC) च्या "भांडवलशाही" मॉडेलभोवती झाली आहे; एक पर्याय, ज्याचे वर्णन कदाचित "विकेंद्रित स्वायत्त समुदाय" म्हणून केले जाऊ शकते, ज्यामध्ये सर्व सदस्यांचा निर्णय प्रक्रियेत समान वाटा असेल आणि सदस्य जोडण्यासाठी किंवा काढण्यासाठी विद्यमान सदस्यांपैकी 67% सदस्यांची संमती आवश्यक असेल. एका व्यक्तीकडे फक्त एकच सदस्यत्व असू शकते ही अट नंतर गटाने एकत्रितपणे लागू करणे आवश्यक असेल.

DAO कसे कोड करावे याची सामान्य रूपरेषा खालीलप्रमाणे आहे. सर्वात सोपी रचना म्हणजे स्वयं-बदलणाऱ्या कोडचा एक भाग जो दोन तृतीयांश सदस्यांनी बदलास सहमती दिल्यास बदलतो. जरी कोड सैद्धांतिकदृष्ट्या अपरिवर्तनीय असला तरी, कोणीही सहजपणे यावर मात करू शकतो आणि कोडचे भाग वेगळ्या कॉन्ट्रॅक्ट्समध्ये ठेवून आणि कोणत्या कॉन्ट्रॅक्ट्सना कॉल करायचे त्यांचा पत्ता बदलण्यायोग्य स्टोरेजमध्ये संचयित करून वास्तविक परिवर्तनशीलता (de-facto mutability) मिळवू शकतो. अशा DAO कॉन्ट्रॅक्टच्या सोप्या अंमलबजावणीमध्ये, व्यवहारात प्रदान केलेल्या डेटानुसार ओळखले जाणारे तीन व्यवहार प्रकार असतील:

• स्टोरेज निर्देशांक K वरील पत्ता V मूल्यामध्ये बदलण्यासाठी निर्देशांक i सह प्रस्ताव नोंदवण्यासाठी [0,i,K,V]
• प्रस्ताव i च्या बाजूने मत नोंदवण्यासाठी [1,i]
• पुरेसे मतदान झाले असल्यास प्रस्ताव i अंतिम करण्यासाठी [2,i]

त्यानंतर कॉन्ट्रॅक्टमध्ये या प्रत्येकासाठी कलमे असतील. ते सर्व खुल्या स्टोरेज बदलांची नोंद ठेवेल, सोबतच त्यांच्यासाठी कोणी मतदान केले याची यादी देखील ठेवेल. त्यात सर्व सदस्यांची यादी देखील असेल. जेव्हा कोणत्याही स्टोरेज बदलाला दोन तृतीयांश सदस्यांचे मतदान मिळते, तेव्हा एक अंतिम व्यवहार तो बदल अंमलात आणू शकतो. अधिक प्रगत साच्यामध्ये व्यवहार पाठवणे, सदस्य जोडणे आणि सदस्य काढून टाकणे यांसारख्या वैशिष्ट्यांसाठी अंगभूत मतदान क्षमता देखील असेल आणि लिक्विड डेमोक्रसी (opens in a new tab)-शैलीतील मत अधिकारप्रदान (म्हणजेच, कोणीही त्यांच्यासाठी मतदान करण्यासाठी कोणालातरी नियुक्त करू शकतो, आणि नियुक्ती संक्रामक असते त्यामुळे जर A ने B ला नियुक्त केले आणि B ने C ला नियुक्त केले तर C हा A चे मत ठरवतो) देखील प्रदान करू शकतो. ही रचना DAO ला विकेंद्रित समुदाय म्हणून सेंद्रियपणे वाढण्याची परवानगी देईल, ज्यामुळे लोकांना शेवटी सदस्य कोण आहे हे फिल्टर करण्याचे काम तज्ञांकडे सोपवण्याची परवानगी मिळेल, जरी "सध्याच्या प्रणाली" च्या विपरीत वैयक्तिक समुदाय सदस्य त्यांचे संरेखन (alignments) बदलत असताना तज्ञ कालांतराने सहजपणे अस्तित्वात येऊ शकतात आणि बाहेर पडू शकतात.

एक पर्यायी मॉडेल विकेंद्रित कॉर्पोरेशनसाठी आहे, जिथे कोणत्याही खात्यात शून्य किंवा अधिक शेअर्स असू शकतात आणि निर्णय घेण्यासाठी दोन तृतीयांश शेअर्स आवश्यक असतात. एका संपूर्ण साच्यामध्ये मालमत्ता व्यवस्थापन कार्यक्षमता, शेअर्स खरेदी किंवा विक्री करण्याची ऑफर देण्याची क्षमता आणि ऑफर्स स्वीकारण्याची क्षमता (शक्यतो कॉन्ट्रॅक्टमध्ये ऑर्डर-मॅचिंग यंत्रणेसह) समाविष्ट असेल. "संचालक मंडळ" या संकल्पनेचे सामान्यीकरण करून, लिक्विड डेमोक्रसी-शैलीत अधिकारप्रदान देखील अस्तित्वात असेल.

पुढील ॲप्लिकेशन्स

1. बचत वॉलेट्स. समजा ॲलिसला तिचा निधी सुरक्षित ठेवायचा आहे, परंतु तिला काळजी आहे की ती तिची खाजगी की गमावेल किंवा कोणीतरी ती हॅक करेल. ती बँक असलेल्या बॉबसोबत खालीलप्रमाणे एका कॉन्ट्रॅक्टमध्ये इथर ठेवते:

• केवळ ॲलिस दररोज जास्तीत जास्त 1% निधी काढू शकते.
• केवळ बॉब दररोज जास्तीत जास्त 1% निधी काढू शकतो, परंतु ॲलिसकडे तिच्या की सह व्यवहार करून ही क्षमता बंद करण्याची क्षमता आहे.
• ॲलिस आणि बॉब मिळून काहीही काढू शकतात.

साधारणपणे, ॲलिससाठी दररोज 1% पुरेसे असते आणि जर ॲलिसला अधिक रक्कम काढायची असेल तर ती मदतीसाठी बॉबशी संपर्क साधू शकते. जर ॲलिसची की हॅक झाली, तर ती निधी नवीन कॉन्ट्रॅक्टमध्ये हलवण्यासाठी बॉबकडे धाव घेते. जर तिने तिची की गमावली, तर बॉब शेवटी निधी बाहेर काढेल. जर बॉब दुर्भावनापूर्ण निघाला, तर ती त्याची रक्कम काढण्याची क्षमता बंद करू शकते.

2. पीक विमा. कोणीही सहजपणे आर्थिक डेरिव्हेटिव्ह्ज कॉन्ट्रॅक्ट बनवू शकतो परंतु कोणत्याही किंमत निर्देशांकाऐवजी हवामानाचा डेटा फीड वापरून. जर आयोवामधील एखाद्या शेतकऱ्याने आयोवामधील पर्जन्यमानावर आधारित व्यस्त प्रमाणात पैसे देणारे डेरिव्हेटिव्ह खरेदी केले, तर दुष्काळ पडल्यास शेतकऱ्याला आपोआप पैसे मिळतील आणि पुरेसा पाऊस पडल्यास शेतकरी आनंदी होईल कारण त्यांचे पीक चांगले येईल. याचा विस्तार साधारणपणे नैसर्गिक आपत्ती विम्यापर्यंत केला जाऊ शकतो.

3. विकेंद्रित डेटा फीड. आर्थिक कॉन्ट्रॅक्ट्स फॉर डिफरन्ससाठी (contracts for difference), "SchellingCoin (opens in a new tab)" नावाच्या प्रोटोकॉलद्वारे डेटा फीडचे विकेंद्रीकरण करणे खरोखर शक्य होऊ शकते. SchellingCoin मुळात खालीलप्रमाणे काम करते: N पक्ष सर्वजण सिस्टममध्ये दिलेल्या डेटाचे मूल्य (उदा. ETH/USD किंमत) टाकतात, मूल्यांची क्रमवारी लावली जाते आणि 25 व्या आणि 75 व्या पर्सेंटाइलमधील प्रत्येकाला बक्षीस म्हणून एक टोकन मिळते. प्रत्येकाला असे उत्तर देण्याचे प्रोत्साहन असते जे इतर सर्वजण देतील, आणि मोठ्या संख्येने खेळाडू ज्या एकमेव मूल्यावर वास्तववादीपणे सहमत होऊ शकतात ते स्पष्ट डीफॉल्ट आहे: सत्य. हे एक विकेंद्रित प्रोटोकॉल तयार करते जे सैद्धांतिकदृष्ट्या ETH/USD किंमत, बर्लिनमधील तापमान किंवा अगदी एखाद्या विशिष्ट कठीण गणनेचा परिणाम यासह कितीही मूल्ये प्रदान करू शकते.

4. स्मार्ट मल्टीसिग एस्क्रो. बिटकॉइन मल्टीसिग व्यवहार कॉन्ट्रॅक्ट्सना अनुमती देते जिथे, उदाहरणार्थ, दिलेल्या पाचपैकी तीन की निधी खर्च करू शकतात. इथेरियम अधिक सूक्ष्मतेची (granularity) अनुमती देते; उदाहरणार्थ, पाचपैकी चार सर्वकाही खर्च करू शकतात, पाचपैकी तीन दररोज 10% पर्यंत खर्च करू शकतात आणि पाचपैकी दोन दररोज 0.5% पर्यंत खर्च करू शकतात. याव्यतिरिक्त, इथेरियम मल्टीसिग असिंक्रोनस (asynchronous) आहे - दोन पक्ष वेगवेगळ्या वेळी ब्लॉकचेनवर त्यांच्या स्वाक्षऱ्या नोंदवू शकतात आणि शेवटची स्वाक्षरी आपोआप व्यवहार पाठवेल.

5. क्लाउड कॉम्प्युटिंग. EVM तंत्रज्ञानाचा वापर पडताळणी करण्यायोग्य संगणकीय वातावरण तयार करण्यासाठी देखील केला जाऊ शकतो, ज्यामुळे वापरकर्त्यांना इतरांना गणना करण्यास सांगता येते आणि नंतर काही यादृच्छिकपणे निवडलेल्या चेकपॉइंट्सवरील गणना योग्यरित्या केली गेली होती याचे पुरावे वैकल्पिकरित्या मागता येतात. हे क्लाउड कॉम्प्युटिंग मार्केट तयार करण्यास अनुमती देते जिथे कोणताही वापरकर्ता त्यांच्या डेस्कटॉप, लॅपटॉप किंवा विशेष सर्व्हरसह सहभागी होऊ शकतो आणि सिस्टम विश्वासार्ह आहे (म्हणजेच, नोड्स फायदेशीरपणे फसवणूक करू शकत नाहीत) याची खात्री करण्यासाठी सुरक्षा ठेवींसह स्पॉट-चेकिंगचा वापर केला जाऊ शकतो. जरी अशी प्रणाली सर्व कार्यांसाठी योग्य नसू शकते; उदाहरणार्थ, ज्या कार्यांसाठी उच्च स्तरावरील आंतर-प्रक्रिया संवादाची (inter-process communication) आवश्यकता असते, ती नोड्सच्या मोठ्या क्लाउडवर सहजपणे केली जाऊ शकत नाहीत. इतर कार्ये मात्र समांतर करणे (parallelize) खूप सोपे आहे; SETI@home, folding@home आणि जेनेटिक अल्गोरिदम यांसारखे प्रकल्प अशा प्लॅटफॉर्मवर सहजपणे लागू केले जाऊ शकतात.

6. पीअर-टू-पीअर जुगार. फ्रँक स्टॅजानो आणि रिचर्ड क्लेटन यांच्या Cyberdice (opens in a new tab) सारखे कितीही पीअर-टू-पीअर जुगार प्रोटोकॉल इथेरियम ब्लॉकचेनवर लागू केले जाऊ शकतात. सर्वात सोपा जुगार प्रोटोकॉल हा प्रत्यक्षात पुढील ब्लॉक हॅशवरील कॉन्ट्रॅक्ट फॉर डिफरन्स आहे आणि तेथून अधिक प्रगत प्रोटोकॉल तयार केले जाऊ शकतात, ज्यामुळे फसवणूक करण्याची क्षमता नसलेल्या आणि जवळपास शून्य शुल्क असलेल्या जुगार सेवा तयार होतात.

7. अंदाज बाजार (Prediction markets). ओरॅकल किंवा SchellingCoin दिल्यास, अंदाज बाजार लागू करणे देखील सोपे आहे, आणि SchellingCoin सोबत अंदाज बाजार हे विकेंद्रित संस्थांसाठी प्रशासन प्रोटोकॉल म्हणून futarchy (opens in a new tab) चे पहिले मुख्य प्रवाहातील ॲप्लिकेशन ठरू शकते.

8. ऑनचेन विकेंद्रित बाजारपेठा, ओळख आणि प्रतिष्ठा प्रणालीचा आधार म्हणून वापर करून.

संकीर्ण आणि चिंता

सुधारित GHOST अंमलबजावणी

"ग्रीडी हेवीएस्ट ऑब्झर्व्हड सबट्री" (GHOST) प्रोटोकॉल हा एक नाविन्यपूर्ण शोध आहे जो योनातन सोम्पोलिन्स्की आणि अवीव जोहर यांनी डिसेंबर 2013 (opens in a new tab) मध्ये प्रथम सादर केला. GHOST मागील उद्देश असा आहे की जलद पुष्टीकरण वेळ असलेल्या ब्लॉकचेन सध्या उच्च स्टेल (stale) दरामुळे कमी सुरक्षिततेचा सामना करतात - कारण ब्लॉक नेटवर्कमध्ये प्रसारित होण्यासाठी ठराविक वेळ घेतात, जर मायनर A ने एक ब्लॉक माइन केला आणि नंतर मायनर A चा ब्लॉक B पर्यंत प्रसारित होण्यापूर्वी मायनर B ने दुसरा ब्लॉक माइन केला, तर मायनर B चा ब्लॉक वाया जाईल आणि नेटवर्क सुरक्षिततेमध्ये योगदान देणार नाही. शिवाय, केंद्रीकरणाची समस्या आहे: जर मायनर A हा 30% हॅशपॉवर असलेला खनन पूल असेल आणि B कडे 10% हॅशपॉवर असेल, तर A ला 70% वेळा स्टेल ब्लॉक तयार करण्याचा धोका असेल (कारण उर्वरित 30% वेळा A ने शेवटचा ब्लॉक तयार केला होता आणि त्यामुळे त्याला खनन डेटा त्वरित मिळेल) तर B ला 90% वेळा स्टेल ब्लॉक तयार करण्याचा धोका असेल. अशा प्रकारे, जर स्टेल दर जास्त असण्यासाठी ब्लॉक अंतराल पुरेसा लहान असेल, तर A केवळ त्याच्या आकारामुळे लक्षणीयरीत्या अधिक कार्यक्षम असेल. या दोन परिणामांच्या संयोजनाने, जे ब्लॉकचेन वेगाने ब्लॉक तयार करतात ते एका खनन पूलकडे नेटवर्क हॅशपॉवरची इतकी मोठी टक्केवारी असण्याची शक्यता निर्माण करतात की त्यांचे खनन प्रक्रियेवर प्रत्यक्ष नियंत्रण असते.

सोम्पोलिन्स्की आणि जोहर यांनी वर्णन केल्याप्रमाणे, GHOST कोणती चेन "सर्वात लांब" आहे याच्या गणनेमध्ये स्टेल ब्लॉक समाविष्ट करून नेटवर्क सुरक्षितता गमावण्याच्या पहिल्या समस्येचे निराकरण करते; म्हणजेच, केवळ ब्लॉकचे पालक आणि पुढील पूर्वजच नाही, तर ब्लॉकच्या पूर्वजांचे स्टेल वंशज (इथेरियमच्या परिभाषेत, "अंकल्स") देखील कोणत्या ब्लॉकला सर्वात मोठे एकूण प्रूफ-ऑफ-वर्क (PoW) समर्थन आहे याच्या गणनेमध्ये जोडले जातात. केंद्रीकरण पक्षपाताच्या दुसऱ्या समस्येचे निराकरण करण्यासाठी, आम्ही सोम्पोलिन्स्की आणि जोहर यांनी वर्णन केलेल्या प्रोटोकॉलच्या पलीकडे जातो आणि स्टेल ब्लॉकला ब्लॉक बक्षीस देखील प्रदान करतो: स्टेल ब्लॉकला त्याच्या मूळ बक्षीसाच्या 87.5% मिळतात आणि स्टेल ब्लॉक समाविष्ट करणाऱ्या पुतण्याला (nephew) उर्वरित 12.5% मिळतात. तथापि, व्यवहार शुल्क अंकल्सना दिले जात नाही.

इथेरियम GHOST ची एक सोपी आवृत्ती लागू करते जी केवळ 7 स्तरांपर्यंत खाली जाते. विशेषतः, हे खालीलप्रमाणे परिभाषित केले आहे:

• एका ब्लॉकने पालक निर्दिष्ट करणे आवश्यक आहे, आणि त्याने 0 किंवा अधिक अंकल्स निर्दिष्ट करणे आवश्यक आहे
• ब्लॉक B मध्ये समाविष्ट असलेल्या अंकलमध्ये खालील गुणधर्म असणे आवश्यक आहे:
  • तो B च्या k-व्या पिढीच्या पूर्वजाचा थेट वंशज असणे आवश्यक आहे, जेथे 2 <= k <= 7.
  • तो B चा पूर्वज असू शकत नाही
  • अंकल एक वैध ब्लॉक हेडर असणे आवश्यक आहे, परंतु तो पूर्वी सत्यापित केलेला किंवा वैध ब्लॉक असण्याची आवश्यकता नाही
  • अंकल मागील ब्लॉकमध्ये समाविष्ट असलेल्या सर्व अंकल्सपेक्षा आणि त्याच ब्लॉकमध्ये समाविष्ट असलेल्या इतर सर्व अंकल्सपेक्षा वेगळा असणे आवश्यक आहे (दुहेरी-समावेश नाही)
• ब्लॉक B मधील प्रत्येक अंकल U साठी, B च्या मायनरला त्याच्या कॉइनबेस बक्षीसामध्ये अतिरिक्त 3.125% जोडले जातात आणि U च्या मायनरला मानक कॉइनबेस बक्षीसाच्या 93.75% मिळतात.

GHOST ची ही मर्यादित आवृत्ती, ज्यामध्ये केवळ 7 पिढ्यांपर्यंत अंकल्स समाविष्ट केले जाऊ शकतात, दोन कारणांसाठी वापरली गेली. पहिले, अमर्यादित GHOST दिलेल्या ब्लॉकसाठी कोणते अंकल्स वैध आहेत याच्या गणनेमध्ये खूप गुंतागुंत निर्माण करेल. दुसरे, इथेरियममध्ये वापरल्याप्रमाणे भरपाईसह अमर्यादित GHOST मायनरला मुख्य चेनवर माइन करण्यासाठी आणि सार्वजनिक हल्लेखोराच्या चेनवर माइन न करण्यासाठी प्रोत्साहन काढून टाकते.

शुल्क

कारण ब्लॉकचेनमध्ये प्रकाशित होणारा प्रत्येक व्यवहार नेटवर्कवर तो डाउनलोड आणि सत्यापित करण्याच्या आवश्यकतेचा खर्च लादतो, गैरवापर टाळण्यासाठी काही नियामक यंत्रणेची आवश्यकता असते, ज्यामध्ये सामान्यतः व्यवहार शुल्क समाविष्ट असते. बिटकॉइनमध्ये वापरला जाणारा डीफॉल्ट दृष्टीकोन म्हणजे पूर्णपणे ऐच्छिक शुल्क असणे, मायनर्सवर द्वारपाल म्हणून काम करण्यासाठी आणि डायनॅमिक किमान मर्यादा सेट करण्यासाठी विसंबून राहणे. हा दृष्टीकोन बिटकॉइन समुदायामध्ये विशेषतः अनुकूलपणे स्वीकारला गेला आहे कारण तो "बाजार-आधारित" आहे, ज्यामुळे मायनर्स आणि व्यवहार पाठवणारे यांच्यातील पुरवठा आणि मागणी किंमत ठरवू देते. तथापि, या युक्तिवादातील समस्या अशी आहे की व्यवहार प्रक्रिया ही बाजारपेठ नाही; जरी व्यवहार प्रक्रियेला मायनर पाठवणाऱ्याला देत असलेली सेवा म्हणून समजणे अंतर्ज्ञानाने आकर्षक असले तरी, प्रत्यक्षात मायनरने समाविष्ट केलेल्या प्रत्येक व्यवहारावर नेटवर्कमधील प्रत्येक नोडद्वारे प्रक्रिया करणे आवश्यक असेल, त्यामुळे व्यवहार प्रक्रियेचा बहुतांश खर्च तृतीय पक्षांद्वारे उचलला जातो आणि तो समाविष्ट करायचा की नाही याचा निर्णय घेणाऱ्या मायनरद्वारे नाही. त्यामुळे, ट्रॅजेडी-ऑफ-द-कॉमन्स (tragedy-of-the-commons) समस्या उद्भवण्याची दाट शक्यता असते.

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

1. एका व्यवहारामुळे k ऑपरेशन्स होतात, जे कोणत्याही मायनरला kR बक्षीस देतात जो तो समाविष्ट करतो जेथे R पाठवणाऱ्याद्वारे सेट केले जाते आणि k आणि R मायनरला आधीच (अंदाजे) दृश्यमान असतात.
2. कोणत्याही नोडसाठी ऑपरेशनचा प्रक्रिया खर्च C असतो (म्हणजेच, सर्व नोड्सची कार्यक्षमता समान असते)
3. N खनन नोड्स आहेत, प्रत्येकाची प्रक्रिया शक्ती अगदी समान आहे (म्हणजेच, एकूणपैकी 1/N)
4. कोणतेही नॉन-खनन पूर्ण नोड अस्तित्वात नाहीत.

जर अपेक्षित बक्षीस खर्चापेक्षा जास्त असेल तर मायनर व्यवहारावर प्रक्रिया करण्यास तयार असेल. अशा प्रकारे, अपेक्षित बक्षीस kR/N आहे कारण मायनरला पुढील ब्लॉकवर प्रक्रिया करण्याची 1/N संधी आहे, आणि मायनरसाठी प्रक्रिया खर्च फक्त kC आहे. त्यामुळे, मायनर्स असे व्यवहार समाविष्ट करतील जेथे kR/N > kC, किंवा R > NC. लक्षात घ्या की R हे पाठवणाऱ्याने दिलेले प्रति-ऑपरेशन शुल्क आहे, आणि अशा प्रकारे पाठवणाऱ्याला व्यवहारातून मिळणाऱ्या फायद्याची ती खालची मर्यादा आहे, आणि NC हा संपूर्ण नेटवर्कला एकत्रितपणे ऑपरेशनवर प्रक्रिया करण्यासाठी येणारा खर्च आहे. त्यामुळे, मायनर्सना केवळ तेच व्यवहार समाविष्ट करण्यासाठी प्रोत्साहन असते ज्यासाठी एकूण उपयुक्ततावादी फायदा खर्चापेक्षा जास्त असतो.

तथापि, प्रत्यक्षात त्या गृहितकांपासून अनेक महत्त्वपूर्ण विचलन आहेत:

1. मायनर इतर पडताळणी नोड्सपेक्षा व्यवहारावर प्रक्रिया करण्यासाठी जास्त खर्च देतो, कारण अतिरिक्त पडताळणी वेळ ब्लॉक प्रसारणास विलंब करतो आणि त्यामुळे ब्लॉक स्टेल होण्याची शक्यता वाढते.
2. नॉन-खनन पूर्ण नोड अस्तित्वात आहेत.
3. खनन शक्ती वितरण प्रत्यक्षात अत्यंत असमान असू शकते.
4. सट्टेबाज, राजकीय शत्रू आणि वेडे लोक ज्यांच्या उपयुक्तता कार्यामध्ये नेटवर्कला हानी पोहोचवणे समाविष्ट आहे ते अस्तित्वात आहेत, आणि ते हुशारीने असे कॉन्ट्रॅक्ट सेट करू शकतात जेथे त्यांचा खर्च इतर पडताळणी नोड्सद्वारे भरलेल्या खर्चापेक्षा खूपच कमी असतो.

(1) मायनरला कमी व्यवहार समाविष्ट करण्याची प्रवृत्ती प्रदान करते, आणि (2) NC वाढवते; त्यामुळे, हे दोन परिणाम किमान अंशतः एकमेकांना रद्द करतात.^{कसे? (opens in a new tab)} (3) आणि (4) ही प्रमुख समस्या आहे; त्यांचे निराकरण करण्यासाठी आम्ही फक्त एक फ्लोटिंग कॅप (floating cap) स्थापित करतो: कोणत्याही ब्लॉकमध्ये दीर्घकालीन घातांकीय मूव्हिंग ॲव्हरेजच्या (exponential moving average) BLK_LIMIT_FACTOR पटीपेक्षा जास्त ऑपरेशन्स असू शकत नाहीत. विशेषतः:

blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) +
floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR)

BLK_LIMIT_FACTOR आणि EMA_FACTOR हे स्थिरांक आहेत जे सध्या 65536 आणि 1.5 वर सेट केले जातील, परंतु पुढील विश्लेषणानंतर ते बदलले जाण्याची शक्यता आहे.

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

संगणन आणि ट्युरिंग-पूर्णता

एक महत्त्वाची नोंद अशी आहे की इथेरियम व्हर्च्युअल मशीन ट्युरिंग-पूर्ण (Turing-complete) आहे; याचा अर्थ असा की EVM कोड कोणत्याही संगणनाला एन्कोड करू शकतो जे शक्यतो पार पाडले जाऊ शकते, ज्यामध्ये अनंत लूप (infinite loops) समाविष्ट आहेत. EVM कोड दोन प्रकारे लूपिंगला अनुमती देतो. पहिले, एक JUMP सूचना आहे जी प्रोग्रामला कोडमधील मागील स्थानावर परत जाण्याची अनुमती देते, आणि सशर्त जंपिंग करण्यासाठी JUMPI सूचना आहे, ज्यामुळे while x < 27: x = x * 2 सारख्या विधानांना अनुमती मिळते. दुसरे, कॉन्ट्रॅक्ट इतर कॉन्ट्रॅक्ट्सना कॉल करू शकतात, ज्यामुळे संभाव्यतः रिकर्शनद्वारे (recursion) लूपिंगला अनुमती मिळते. यामुळे साहजिकच एक समस्या निर्माण होते: दुर्भावनापूर्ण वापरकर्ते मायनर्स आणि पूर्ण नोड्सना अनंत लूपमध्ये प्रवेश करण्यास भाग पाडून त्यांना बंद करू शकतात का? ही समस्या संगणक विज्ञानातील हॉल्टिंग प्रॉब्लेम (halting problem) म्हणून ओळखल्या जाणाऱ्या समस्येमुळे उद्भवते: सामान्य बाबतीत, दिलेला प्रोग्राम कधी थांबेल की नाही हे सांगण्याचा कोणताही मार्ग नाही.

स्थिती संक्रमण विभागात वर्णन केल्याप्रमाणे, आमचे समाधान व्यवहाराला जास्तीत जास्त संगणकीय पायऱ्या सेट करणे आवश्यक करून कार्य करते ज्या घेण्याची त्याला परवानगी आहे, आणि जर अंमलबजावणीस जास्त वेळ लागला तर संगणन पूर्ववत केले जाते परंतु शुल्क अद्याप भरले जाते. संदेश त्याच प्रकारे कार्य करतात. आमच्या समाधानामागील उद्देश दर्शविण्यासाठी, खालील उदाहरणांचा विचार करा:

• एक हल्लेखोर एक कॉन्ट्रॅक्ट तयार करतो जो अनंत लूप चालवतो, आणि नंतर तो लूप सक्रिय करणारा व्यवहार मायनरला पाठवतो. मायनर व्यवहारावर प्रक्रिया करेल, अनंत लूप चालवेल आणि गॅस संपेपर्यंत वाट पाहेल. जरी अंमलबजावणीचा गॅस संपला आणि ती अर्ध्यावर थांबली, तरीही व्यवहार वैध असतो आणि मायनर अद्याप प्रत्येक संगणकीय पायरीसाठी हल्लेखोराकडून शुल्काचा दावा करतो.
• एक हल्लेखोर मायनरला इतक्या दीर्घकाळापर्यंत संगणन करत राहण्यास भाग पाडण्याच्या उद्देशाने एक अतिशय लांब अनंत लूप तयार करतो की संगणन पूर्ण होईपर्यंत आणखी काही ब्लॉक बाहेर आले असतील आणि मायनरला शुल्काचा दावा करण्यासाठी व्यवहार समाविष्ट करणे शक्य होणार नाही. तथापि, हल्लेखोराला अंमलबजावणी घेऊ शकणाऱ्या संगणकीय पायऱ्यांची संख्या मर्यादित करण्यासाठी STARTGAS साठी मूल्य सबमिट करणे आवश्यक असेल, त्यामुळे मायनरला आधीच माहित असेल की संगणनासाठी खूप जास्त पायऱ्या लागतील.
• एक हल्लेखोर send(A,contract.storage[A]); contract.storage[A] = 0 सारख्या काही स्वरूपाच्या कोडसह एक कॉन्ट्रॅक्ट पाहतो, आणि पहिली पायरी चालवण्यासाठी पुरेशा गॅससह व्यवहार पाठवतो परंतु दुसरी नाही (म्हणजेच, रक्कम काढणे परंतु शिल्लक कमी होऊ न देणे). कॉन्ट्रॅक्ट लेखकाला अशा हल्ल्यांपासून संरक्षण करण्याबद्दल काळजी करण्याची आवश्यकता नाही, कारण जर अंमलबजावणी अर्ध्यावर थांबली तर बदल पूर्ववत केले जातात.
• जोखीम कमी करण्यासाठी एक आर्थिक कॉन्ट्रॅक्ट नऊ मालकीच्या डेटा फीड्सचा मध्यक (median) घेऊन कार्य करतो. एक हल्लेखोर एका डेटा फीडचा ताबा घेतो, जो DAO वरील विभागात वर्णन केलेल्या व्हेरिएबल-ॲड्रेस-कॉल यंत्रणेद्वारे सुधारण्यायोग्य करण्यासाठी डिझाइन केलेला आहे, आणि तो अनंत लूप चालवण्यासाठी रूपांतरित करतो, ज्यामुळे आर्थिक कॉन्ट्रॅक्टमधून निधीचा दावा करण्याच्या कोणत्याही प्रयत्नांना गॅस संपण्यास भाग पाडण्याचा प्रयत्न करतो. तथापि, ही समस्या टाळण्यासाठी आर्थिक कॉन्ट्रॅक्ट संदेशावर गॅस मर्यादा सेट करू शकतो.

ट्युरिंग-पूर्णतेचा पर्याय ट्युरिंग-अपूर्णता (Turing-incompleteness) आहे, जेथे JUMP आणि JUMPI अस्तित्वात नाहीत आणि कोणत्याही दिलेल्या वेळी कॉल स्टॅकमध्ये प्रत्येक कॉन्ट्रॅक्टची केवळ एक प्रत अस्तित्वात असण्याची परवानगी आहे. या प्रणालीसह, वर्णन केलेली शुल्क प्रणाली आणि आमच्या समाधानाच्या परिणामकारकतेबद्दलची अनिश्चितता आवश्यक नसू शकते, कारण कॉन्ट्रॅक्ट कार्यान्वित करण्याचा खर्च त्याच्या आकारानुसार मर्यादित असेल. याव्यतिरिक्त, ट्युरिंग-अपूर्णता ही इतकी मोठी मर्यादा देखील नाही; आम्ही अंतर्गतपणे कल्पिलेल्या सर्व कॉन्ट्रॅक्ट उदाहरणांपैकी, आतापर्यंत केवळ एकाला लूपची आवश्यकता होती, आणि तो लूप देखील एका ओळीच्या कोडची 26 पुनरावृत्ती करून काढला जाऊ शकतो. ट्युरिंग-पूर्णतेचे गंभीर परिणाम आणि मर्यादित फायदा लक्षात घेता, फक्त ट्युरिंग-अपूर्ण भाषा का असू नये? प्रत्यक्षात, तथापि, ट्युरिंग-अपूर्णता या समस्येवर एक व्यवस्थित उपाय नाही. का ते पाहण्यासाठी, खालील कॉन्ट्रॅक्ट्सचा विचार करा:

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (run one step of a program and record the change in storage)

आता, A ला एक व्यवहार पाठवा. अशा प्रकारे, 51 व्यवहारांमध्ये, आमच्याकडे एक कॉन्ट्रॅक्ट आहे जो 2⁵⁰ संगणकीय पायऱ्या घेतो. मायनर्स प्रत्येक कॉन्ट्रॅक्टसोबत एक मूल्य राखून अशा लॉजिक बॉम्ब्सचा (logic bombs) आधीच शोध घेण्याचा प्रयत्न करू शकतात जे ते घेऊ शकणाऱ्या जास्तीत जास्त संगणकीय पायऱ्या निर्दिष्ट करतात, आणि इतर कॉन्ट्रॅक्ट्सना रिकर्सिव्हली कॉल करणाऱ्या कॉन्ट्रॅक्ट्ससाठी याची गणना करू शकतात, परंतु त्यासाठी मायनर्सना इतर कॉन्ट्रॅक्ट्स तयार करणाऱ्या कॉन्ट्रॅक्ट्सना मनाई करणे आवश्यक असेल (कारण वरील सर्व 26 कॉन्ट्रॅक्ट्सची निर्मिती आणि अंमलबजावणी सहजपणे एकाच कॉन्ट्रॅक्टमध्ये गुंडाळली जाऊ शकते). आणखी एक समस्याप्रधान मुद्दा असा आहे की संदेशाचे पत्ता क्षेत्र एक व्हेरिएबल आहे, त्यामुळे सर्वसाधारणपणे दिलेला कॉन्ट्रॅक्ट कोणत्या इतर कॉन्ट्रॅक्ट्सना कॉल करेल हे आधीच सांगणे शक्य होणार नाही. त्यामुळे, एकंदरीत, आमच्याकडे एक आश्चर्यकारक निष्कर्ष आहे: ट्युरिंग-पूर्णता व्यवस्थापित करणे आश्चर्यकारकपणे सोपे आहे, आणि ट्युरिंग-पूर्णतेचा अभाव व्यवस्थापित करणे तितकेच आश्चर्यकारकपणे कठीण आहे जोपर्यंत तशीच नियंत्रणे लागू नसतात - परंतु त्या बाबतीत प्रोटोकॉलला ट्युरिंग-पूर्ण का राहू देऊ नये?

चलन आणि निर्गमन

इथेरियम नेटवर्कमध्ये स्वतःचे अंगभूत चलन, इथर समाविष्ट आहे, जे विविध प्रकारच्या डिजिटल मालमत्तांमध्ये कार्यक्षम अदलाबदल करण्यासाठी प्राथमिक तरलता स्तर प्रदान करण्याचा आणि अधिक महत्त्वाचे म्हणजे, व्यवहार शुल्क भरण्यासाठी एक यंत्रणा प्रदान करण्याचा दुहेरी उद्देश पूर्ण करते. सोयीसाठी आणि भविष्यातील युक्तिवाद टाळण्यासाठी (बिटकॉइनमधील सध्याचा mBTC/uBTC/satoshi वाद पहा), मूल्यांना पूर्व-लेबल केले जाईल:

• 1: Wei
• 10¹²: साबो
• 10¹⁵: फिनी
• 10¹⁸: इथर

हे "डॉलर्स" आणि "सेंट्स" किंवा "BTC" आणि "satoshi" या संकल्पनेची विस्तारित आवृत्ती म्हणून घेतले पाहिजे. नजीकच्या भविष्यात, आम्हाला अपेक्षा आहे की "इथर" सामान्य व्यवहारांसाठी, "फिनी" मायक्रो ट्रान्झॅक्शन्ससाठी आणि "साबो" आणि "Wei" शुल्क आणि प्रोटोकॉल अंमलबजावणीच्या तांत्रिक चर्चांसाठी वापरले जाईल; उर्वरित मूल्ये नंतर उपयुक्त ठरू शकतात आणि या टप्प्यावर क्लायंटमध्ये समाविष्ट केली जाऊ नयेत.

निर्गमन मॉडेल खालीलप्रमाणे असेल:

• इथर चलन विक्रीमध्ये 1000-2000 इथर प्रति BTC या दराने जारी केले जाईल, ही एक यंत्रणा आहे जिचा उद्देश इथेरियम संस्थेला निधी देणे आणि विकासासाठी पैसे देणे हा आहे जी मास्टरकॉइन (Mastercoin) आणि NXT सारख्या इतर प्लॅटफॉर्मद्वारे यशस्वीरित्या वापरली गेली आहे. सुरुवातीच्या खरेदीदारांना मोठ्या सवलतींचा फायदा होईल. विक्रीतून मिळालेले BTC पूर्णपणे विकासकांना पगार आणि बक्षिसे देण्यासाठी वापरले जातील आणि इथेरियम आणि क्रिप्टोकरन्सी इकोसिस्टममधील विविध नफा-केंद्री आणि ना-नफा प्रकल्पांमध्ये गुंतवले जातील.
• विकल्या गेलेल्या एकूण रकमेच्या 0.099x (60102216 ETH) संस्थेला सुरुवातीच्या योगदानकर्त्यांना भरपाई देण्यासाठी आणि उत्पत्ती ब्लॉकच्या आधी ETH-मूल्यांकित खर्च भरण्यासाठी वाटप केले जाईल.
• विकल्या गेलेल्या एकूण रकमेच्या 0.099x दीर्घकालीन राखीव निधी म्हणून राखले जाईल.
• विकल्या गेलेल्या एकूण रकमेच्या 0.26x त्या बिंदूनंतर कायमचे दरवर्षी मायनर्सना वाटप केले जाईल.

दीर्घकालीन पुरवठा वाढीचा दर (टक्के)

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

वरील मॉडेलमधील दोन मुख्य पर्याय म्हणजे (1) एंडोमेंट पूलचे (endowment pool) अस्तित्व आणि आकार, आणि (2) बिटकॉइनप्रमाणे मर्यादित पुरवठ्याच्या विरूद्ध, कायमस्वरूपी वाढणाऱ्या रेषीय पुरवठ्याचे अस्तित्व. एंडोमेंट पूलचे समर्थन खालीलप्रमाणे आहे. जर एंडोमेंट पूल अस्तित्वात नसता, आणि समान महागाई दर प्रदान करण्यासाठी रेषीय निर्गमन 0.217x पर्यंत कमी केले असते, तर इथरचे एकूण प्रमाण 16.5% कमी झाले असते आणि त्यामुळे प्रत्येक युनिट 19.8% अधिक मौल्यवान झाले असते. त्यामुळे, समतोलामध्ये विक्रीत 19.8% अधिक इथर खरेदी केले गेले असते, त्यामुळे प्रत्येक युनिट पुन्हा एकदा पूर्वीइतकेच मौल्यवान झाले असते. संस्थेकडे 1.198x इतके BTC देखील असते, जे दोन भागांमध्ये विभागले गेले आहे असे मानले जाऊ शकते: मूळ BTC, आणि अतिरिक्त 0.198x. त्यामुळे, ही परिस्थिती एंडोमेंटच्या अगदी समतुल्य आहे, परंतु एका महत्त्वाच्या फरकासह: संस्थेकडे पूर्णपणे BTC आहे, आणि त्यामुळे इथर युनिटच्या मूल्याला समर्थन देण्यासाठी प्रोत्साहित केले जात नाही.

कायमस्वरूपी रेषीय पुरवठा वाढीचे मॉडेल बिटकॉइनमधील अत्यधिक संपत्ती केंद्रीकरण म्हणून काही लोक जे पाहतात त्याचा धोका कमी करते, आणि वर्तमान आणि भविष्यातील युगांमध्ये राहणाऱ्या व्यक्तींना चलन युनिट्स मिळवण्याची योग्य संधी देते, त्याच वेळी इथर मिळवण्यासाठी आणि धारण करण्यासाठी एक मजबूत प्रोत्साहन राखून ठेवते कारण टक्केवारी म्हणून "पुरवठा वाढीचा दर" अद्याप कालांतराने शून्याकडे झुकतो. आम्ही असा सिद्धांत देखील मांडतो की निष्काळजीपणा, मृत्यू इत्यादींमुळे कालांतराने नाणी नेहमीच गमावली जातात आणि नाण्यांचे नुकसान दरवर्षी एकूण पुरवठ्याची टक्केवारी म्हणून मॉडेल केले जाऊ शकते, त्यामुळे चलनात असलेला एकूण चलन पुरवठा प्रत्यक्षात शेवटी वार्षिक निर्गमनाला नुकसान दराने भागून मिळणाऱ्या मूल्यावर स्थिर होईल (उदा., 1% च्या नुकसान दराने, एकदा पुरवठा 26X वर पोहोचला की 0.26X माइन केले जाईल आणि दरवर्षी 0.26X गमावले जाईल, ज्यामुळे समतोल निर्माण होईल).

लक्षात घ्या की भविष्यात, सुरक्षिततेसाठी इथेरियम प्रूफ-ऑफ-स्टेक (PoS) मॉडेलवर स्विच करेल अशी शक्यता आहे, ज्यामुळे निर्गमन आवश्यकता दरवर्षी शून्य ते 0.05X च्या दरम्यान कमी होईल. जर इथेरियम संस्थेने निधी गमावला किंवा इतर कोणत्याही कारणास्तव ती नाहीशी झाली, तर आम्ही एक "सामाजिक करार" खुला ठेवतो: कोणालाही इथेरियमची भविष्यातील उमेदवार आवृत्ती तयार करण्याचा अधिकार आहे, ज्याची एकमेव अट अशी आहे की इथरचे प्रमाण जास्तीत जास्त 60102216 * (1.198 + 0.26 * n) च्या समान असणे आवश्यक आहे जेथे n हे उत्पत्ती ब्लॉकनंतरच्या वर्षांची संख्या आहे. निर्माते विकासासाठी पैसे देण्यासाठी PoS-चालित पुरवठा विस्तार आणि जास्तीत जास्त अनुज्ञेय पुरवठा विस्तार यामधील काही किंवा सर्व फरक क्राउड-सेल (crowd-sell) करण्यासाठी किंवा अन्यथा नियुक्त करण्यासाठी मुक्त आहेत. सामाजिक कराराचे पालन न करणारे उमेदवार अपग्रेड्स न्याय्यपणे अनुपालन करणाऱ्या आवृत्त्यांमध्ये फोर्क केले जाऊ शकतात.

खनन केंद्रीकरण

बिटकॉइन खनन अल्गोरिदम मायनर्सना ब्लॉक हेडरच्या किंचित सुधारित आवृत्त्यांवर लाखो वेळा पुन्हा पुन्हा SHA256 ची गणना करून कार्य करते, जोपर्यंत शेवटी एका नोडला अशी आवृत्ती मिळत नाही जिचा हॅश लक्ष्यापेक्षा कमी असतो (सध्या सुमारे 2¹⁹²). तथापि, हे खनन अल्गोरिदम दोन प्रकारच्या केंद्रीकरणास असुरक्षित आहे. पहिले, खनन इकोसिस्टमवर ASIC (ॲप्लिकेशन-स्पेसिफिक इंटिग्रेटेड सर्किट्स) चे वर्चस्व निर्माण झाले आहे, ज्या संगणक चिप्स बिटकॉइन खननच्या विशिष्ट कार्यासाठी डिझाइन केलेल्या आहेत आणि त्यामुळे हजारो पटीने अधिक कार्यक्षम आहेत. याचा अर्थ असा की बिटकॉइन खनन आता अत्यंत विकेंद्रित आणि समतावादी प्रयत्न राहिलेला नाही, ज्यामध्ये प्रभावीपणे सहभागी होण्यासाठी लाखो डॉलर्सच्या भांडवलाची आवश्यकता असते. दुसरे, बहुतेक बिटकॉइन मायनर्स प्रत्यक्षात स्थानिक पातळीवर ब्लॉक प्रमाणीकरण करत नाहीत; त्याऐवजी, ते ब्लॉक हेडर प्रदान करण्यासाठी केंद्रीकृत खनन पूलवर अवलंबून असतात. ही समस्या अधिक वाईट आहे: हे लिहित असताना, शीर्ष तीन खनन पूल अप्रत्यक्षपणे बिटकॉइन नेटवर्कमधील सुमारे 50% प्रक्रिया शक्ती नियंत्रित करतात, जरी हे या वस्तुस्थितीमुळे कमी झाले आहे की जर एखादा पूल किंवा युती 51% हल्ला करण्याचा प्रयत्न करत असेल तर मायनर्स इतर खनन पूलमध्ये स्विच करू शकतात.

इथेरियमचा सध्याचा उद्देश असा खनन अल्गोरिदम वापरण्याचा आहे जेथे मायनर्सना स्थितीतून यादृच्छिक डेटा आणणे, ब्लॉकचेनमधील मागील N ब्लॉक्समधून काही यादृच्छिकपणे निवडलेल्या व्यवहारांची गणना करणे आणि परिणामाचा हॅश परत करणे आवश्यक आहे. याचे दोन महत्त्वाचे फायदे आहेत. पहिले, इथेरियम कॉन्ट्रॅक्ट्समध्ये कोणत्याही प्रकारचे संगणन समाविष्ट असू शकते, त्यामुळे इथेरियम ASIC हे मूलत: सामान्य संगणनासाठी ASIC असेल - म्हणजेच, एक चांगला CPU. दुसरे, खननसाठी संपूर्ण ब्लॉकचेनमध्ये प्रवेश आवश्यक आहे, ज्यामुळे मायनर्सना संपूर्ण ब्लॉकचेन संचयित करण्यास आणि किमान प्रत्येक व्यवहार सत्यापित करण्यास सक्षम होण्यास भाग पाडले जाते. यामुळे केंद्रीकृत खनन पूलची आवश्यकता दूर होते; जरी खनन पूल अद्याप बक्षीस वितरणाची यादृच्छिकता समान करण्याची कायदेशीर भूमिका बजावू शकतात, तरीही हे कार्य कोणत्याही केंद्रीय नियंत्रणाशिवाय पीअर-टू-पीअर पूलद्वारे तितक्याच चांगल्या प्रकारे केले जाऊ शकते.

हे मॉडेल तपासलेले नाही, आणि खनन अल्गोरिदम म्हणून कॉन्ट्रॅक्ट अंमलबजावणी वापरताना काही हुशार ऑप्टिमायझेशन्स टाळण्यात वाटेत अडचणी येऊ शकतात. तथापि, या अल्गोरिदमचे एक विशेषतः मनोरंजक वैशिष्ट्य म्हणजे ते कोणालाही "विहीर विषारी" (poison the well) करण्याची अनुमती देते, विशिष्ट ASIC ला अडथळा आणण्यासाठी विशेषतः डिझाइन केलेले मोठ्या संख्येने कॉन्ट्रॅक्ट्स ब्लॉकचेनमध्ये आणून. ASIC उत्पादकांना एकमेकांवर हल्ला करण्यासाठी अशा युक्तीचा वापर करण्यासाठी आर्थिक प्रोत्साहन अस्तित्वात आहे. अशा प्रकारे, आम्ही विकसित करत असलेले समाधान शेवटी पूर्णपणे तांत्रिक उपायाऐवजी एक अनुकूली आर्थिक मानवी समाधान आहे.

स्केलेबिलिटी

इथेरियमबद्दल एक सामान्य चिंता स्केलेबिलिटीची (scalability) समस्या आहे. बिटकॉइनप्रमाणेच, इथेरियममध्ये ही त्रुटी आहे की प्रत्येक व्यवहारावर नेटवर्कमधील प्रत्येक नोडद्वारे प्रक्रिया करणे आवश्यक आहे. बिटकॉइनसह, सध्याच्या ब्लॉकचेनचा आकार सुमारे 15 GB आहे, जो प्रति तास सुमारे 1 MB ने वाढत आहे. जर बिटकॉइन नेटवर्कने व्हिसाच्या (Visa) प्रति सेकंद 2000 व्यवहारांवर प्रक्रिया केली, तर ते प्रति तीन सेकंदाला 1 MB ने वाढेल (1 GB प्रति तास, 8 TB प्रति वर्ष). इथेरियमला अशाच प्रकारच्या वाढीच्या नमुन्याचा सामना करावा लागण्याची शक्यता आहे, जे या वस्तुस्थितीमुळे अधिक वाईट झाले आहे की बिटकॉइनच्या बाबतीत केवळ चलनाऐवजी इथेरियम ब्लॉकचेनच्या वर अनेक ॲप्लिकेशन्स असतील, परंतु या वस्तुस्थितीमुळे सुधारले आहे की इथेरियम पूर्ण नोड्सना संपूर्ण ब्लॉकचेन इतिहासाऐवजी केवळ स्थिती संचयित करणे आवश्यक आहे.

इतक्या मोठ्या ब्लॉकचेन आकाराची समस्या केंद्रीकरणाचा धोका आहे. जर ब्लॉकचेनचा आकार, समजा, 100 TB पर्यंत वाढला, तर संभाव्य परिस्थिती अशी असेल की केवळ खूप कमी संख्येने मोठे व्यवसाय पूर्ण नोड चालवतील, आणि सर्व नियमित वापरकर्ते लाईट SPV नोड्स वापरतील. अशा परिस्थितीत, अशी संभाव्य चिंता निर्माण होते की पूर्ण नोड एकत्र येऊ शकतात आणि सर्वजण काही फायदेशीर मार्गाने फसवणूक करण्यास सहमत होऊ शकतात (उदा., ब्लॉक बक्षीस बदलणे, स्वतःला BTC देणे). लाईट नोड्सना हे त्वरित शोधण्याचा कोणताही मार्ग नसेल. अर्थात, किमान एक प्रामाणिक पूर्ण नोड अस्तित्वात असण्याची शक्यता आहे, आणि काही तासांनंतर फसवणुकीची माहिती रेडिट् सारख्या चॅनेलद्वारे बाहेर येईल, परंतु त्या टप्प्यावर खूप उशीर झालेला असेल: दिलेल्या ब्लॉक्सना ब्लॅकलिस्ट करण्यासाठी प्रयत्न आयोजित करणे सामान्य वापरकर्त्यांवर अवलंबून असेल, जी यशस्वी 51% हल्ला करण्याच्या समान प्रमाणावरील एक मोठी आणि संभाव्यतः अशक्य समन्वय समस्या आहे. बिटकॉइनच्या बाबतीत, ही सध्या एक समस्या आहे, परंतु पीटर टॉड यांनी सुचवलेला (opens in a new tab) एक ब्लॉकचेन बदल अस्तित्वात आहे जो ही समस्या कमी करेल.

नजीकच्या काळात, इथेरियम या समस्येचा सामना करण्यासाठी दोन अतिरिक्त रणनीती वापरेल. पहिले, ब्लॉकचेन-आधारित खनन अल्गोरिदममुळे, किमान प्रत्येक मायनरला पूर्ण नोड होण्यास भाग पाडले जाईल, ज्यामुळे पूर्ण नोड्सच्या संख्येवर खालची मर्यादा निर्माण होईल. दुसरे आणि अधिक महत्त्वाचे म्हणजे, तथापि, आम्ही प्रत्येक व्यवहारावर प्रक्रिया केल्यानंतर ब्लॉकचेनमध्ये एक मध्यवर्ती स्थिती ट्री रूट (state tree root) समाविष्ट करू. जरी ब्लॉक प्रमाणीकरण केंद्रीकृत असले तरी, जोपर्यंत एक प्रामाणिक पडताळणी नोड अस्तित्वात आहे, तोपर्यंत पडताळणी प्रोटोकॉलद्वारे केंद्रीकरण समस्येला बगल दिली जाऊ शकते. जर मायनरने अवैध ब्लॉक प्रकाशित केला, तर तो ब्लॉक एकतर खराब फॉरमॅट केलेला असणे आवश्यक आहे, किंवा स्थिती S[n] चुकीची आहे. कारण S[0] योग्य असल्याचे ज्ञात आहे, काही पहिली स्थिती S[i] असणे आवश्यक आहे जी चुकीची आहे जेथे S[i-1] योग्य आहे. पडताळणी नोड निर्देशांक i प्रदान करेल, सोबत "अवैधतेचा पुरावा" ज्यामध्ये APPLY(S[i-1],TX[i]) -> S[i] वर प्रक्रिया करण्यासाठी आवश्यक असलेल्या पॅट्रिशिया ट्री (Patricia tree) नोड्सचा उपसंच असेल. नोड्स संगणनाचा तो भाग चालवण्यासाठी त्या नोड्सचा वापर करण्यास सक्षम असतील, आणि पाहतील की व्युत्पन्न झालेले S[i] प्रदान केलेल्या S[i] शी जुळत नाही.

आणखी एका, अधिक अत्याधुनिक हल्ल्यामध्ये दुर्भावनापूर्ण मायनर्स अपूर्ण ब्लॉक प्रकाशित करतील, त्यामुळे ब्लॉक वैध आहेत की नाही हे निर्धारित करण्यासाठी संपूर्ण माहिती देखील अस्तित्वात नसते. यावरील उपाय म्हणजे चॅलेंज-रिस्पॉन्स (challenge-response) प्रोटोकॉल: पडताळणी नोड्स लक्ष्य व्यवहार निर्देशांकांच्या स्वरूपात "आव्हाने" जारी करतात, आणि नोड प्राप्त झाल्यावर लाईट नोड ब्लॉकला अविश्वासू मानतो जोपर्यंत दुसरा नोड, मग तो मायनर असो किंवा दुसरा पडताळणीकर्ता, वैधतेचा पुरावा म्हणून पॅट्रिशिया नोड्सचा उपसंच प्रदान करत नाही.

निष्कर्ष

इथेरियम प्रोटोकॉलची मूळ संकल्पना क्रिप्टोकरन्सीची एक सुधारित आवृत्ती म्हणून करण्यात आली होती, जी अत्यंत सामान्यीकृत प्रोग्रामिंग भाषेच्या माध्यमातून ऑन-ब्लॉकचेन एस्क्रो, रक्कम काढण्याच्या मर्यादा, आर्थिक कॉन्ट्रॅक्ट्स, जुगाराचे बाजार आणि यांसारखी प्रगत वैशिष्ट्ये प्रदान करते. इथेरियम प्रोटोकॉल कोणत्याही ॲप्लिकेशन्सना थेट "समर्थन" देणार नाही, परंतु ट्युरिंग-कंप्लीट प्रोग्रामिंग भाषेच्या अस्तित्वाचा अर्थ असा आहे की कोणत्याही प्रकारच्या व्यवहारासाठी किंवा ॲप्लिकेशनसाठी सैद्धांतिकदृष्ट्या अनियंत्रित कॉन्ट्रॅक्ट्स तयार केले जाऊ शकतात. तथापि, इथेरियमबद्दल अधिक मनोरंजक गोष्ट ही आहे की इथेरियम प्रोटोकॉल केवळ चलनापलीकडे खूप पुढे जातो. विकेंद्रित फाईल स्टोरेज, विकेंद्रित संगणन आणि विकेंद्रित अंदाज बाजार यांसारख्या डझनभर इतर संकल्पनांवरील प्रोटोकॉल्समध्ये संगणकीय उद्योगाची कार्यक्षमता लक्षणीयरीत्या वाढवण्याची क्षमता आहे, आणि पहिल्यांदाच एक आर्थिक स्तर जोडून इतर पीअर-टू-पीअर प्रोटोकॉल्सना मोठ्या प्रमाणावर चालना देण्याची क्षमता आहे. शेवटी, अशा ॲप्लिकेशन्सची एक मोठी श्रेणी देखील आहे ज्यांचा पैशाशी काहीही संबंध नाही.

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

टिपा आणि पुढील वाचन

टिपा

1. एका जाणकार वाचकाच्या लक्षात येईल की प्रत्यक्षात बिटकॉइन पत्ता हा लंबवर्तुळाकार वक्र सार्वजनिक कीचा हॅश असतो, आणि ती स्वतः सार्वजनिक की नसते. तथापि, पबकी (pubkey) हॅशलाच सार्वजनिक की म्हणणे ही पूर्णपणे वैध गूढलेखन संज्ञा आहे. याचे कारण असे की बिटकॉइनचे गूढलेखन हे एक सानुकूल डिजिटल स्वाक्षरी अल्गोरिदम मानले जाऊ शकते, ज्यामध्ये सार्वजनिक कीमध्ये ECC पबकीचा हॅश असतो, स्वाक्षरीमध्ये ECC पबकी आणि ECC स्वाक्षरी एकत्र जोडलेली असते, आणि पडताळणी अल्गोरिदममध्ये स्वाक्षरीमधील ECC पबकीची सार्वजनिक की म्हणून प्रदान केलेल्या ECC पबकी हॅशसोबत तपासणी करणे आणि नंतर ECC पबकीच्या विरूद्ध ECC स्वाक्षरीची पडताळणी करणे समाविष्ट असते.
2. तांत्रिकदृष्ट्या, मागील 11 ब्लॉकचा मध्यक.
3. अंतर्गतरीत्या, 2 आणि "CHARLIE" हे दोन्ही क्रमांक आहेत, ज्यामध्ये नंतरचा क्रमांक बिग-एन्डियन बेस 256 सादरीकरणात आहे. क्रमांक किमान 0 आणि कमाल 2²⁵⁶-1 असू शकतात.

पुढील वाचन

1. अंगभूत मूल्य (opens in a new tab)
2. स्मार्ट मालमत्ता (opens in a new tab)
3. स्मार्ट कॉन्ट्रॅक्ट्स (opens in a new tab)
4. B-money (opens in a new tab)
5. पुन्हा वापरण्यायोग्य प्रूफ-ऑफ-वर्क (opens in a new tab)
6. मालकाच्या अधिकारासह सुरक्षित मालमत्ता शीर्षके (opens in a new tab)
7. बिटकॉइन श्वेतपत्रिका (opens in a new tab)
8. Namecoin (opens in a new tab)
9. झूकोचा त्रिकोण (opens in a new tab)
10. कलर्ड कॉइन्स श्वेतपत्रिका (opens in a new tab)
11. मास्टरकॉइन श्वेतपत्रिका (opens in a new tab)
12. विकेंद्रित स्वायत्त कॉर्पोरेशन्स, बिटकॉइन मॅगझिन (opens in a new tab)
13. सरलीकृत पेमेंट पडताळणी (opens in a new tab)
14. मर्कल ट्रीज (opens in a new tab)
15. पॅट्रिशिया ट्रीज (opens in a new tab)
16. GHOST (opens in a new tab)
17. StorJ आणि ऑटोनॉमस एजंट्स, जेफ गार्झिक (opens in a new tab)
18. ट्युरिंग फेस्टिव्हलमध्ये स्मार्ट मालमत्तेवर माईक हर्न (opens in a new tab)
19. इथेरियम RLP
20. इथेरियम मर्कल पॅट्रिशिया ट्रीज
21. मर्कल सम ट्रीजवर पीटर टॉड (opens in a new tab)

श्वेतपत्रिकेच्या इतिहासासाठी, ही विकी (opens in a new tab) पहा.

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