इथेरियम व्हाइटपेपर

हा प्रास्ताविक पेपर मूळतः 2014 मध्ये इथेरियमचे संस्थापक विटालिक बुटेरिन यांनी 2015 मध्ये प्रकल्पाच्या प्रक्षेपणापूर्वी प्रकाशित केला होता. हे लक्षात घेण्यासारखे आहे की इथेरियम, अनेक समुदाय-चालित, ओपन-सोर्स सॉफ्टवेअर प्रकल्पांप्रमाणे, त्याच्या सुरुवातीच्या स्थापनेपासून विकसित झाले आहे.

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

व्हाइटपेपरची ऐतिहासिक किंवा प्रमाणभूत आवृत्ती [डिसेंबर 2014 पासून] शोधणाऱ्या संशोधक आणि शिक्षणतज्ञांनी ही PDF वापरावी.

एक नेक्स्ट-जनरेशन स्मार्ट कॉन्ट्रॅक्ट आणि डिसेंट्रलाइज्ड ॲप्लिकेशन प्लॅटफॉर्म

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

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

इतिहास

विकेंद्रीकृत डिजिटल चलनाची संकल्पना, तसेच मालमत्ता नोंदणीसारख्या पर्यायी अनुप्रयोगांची संकल्पना अनेक दशकांपासून अस्तित्वात आहे. 1980 आणि 1990 च्या दशकातील अनामिक ई-कॅश प्रोटोकॉल, जे बहुतेक चॉमियन ब्लाइंडिंग म्हणून ओळखल्या जाणार्‍या क्रिप्टोग्राफिक प्रिमिटिव्हवर अवलंबून होते, त्यांनी उच्च गोपनीयतेसह चलन प्रदान केले, परंतु केंद्रीकृत मध्यस्थांवर अवलंबून असल्यामुळे हे प्रोटोकॉल मोठ्या प्रमाणात यशस्वी होऊ शकले नाहीत. 1998 मध्ये, वेई दाईचा b-moneyopens in a new tab हा संगणकीय कोडी सोडवून आणि विकेंद्रित सहमतीने पैसे तयार करण्याची कल्पना मांडणारा पहिला प्रस्ताव बनला, परंतु विकेंद्रित सहमती प्रत्यक्षात कशी लागू केली जाऊ शकते याबद्दल प्रस्तावात तपशीलांची कमतरता होती. 2005 मध्ये, हॅल फिनी यांनी "reusable proofs of workopens in a new tab" ची संकल्पना मांडली, ही एक प्रणाली आहे जी b-money च्या कल्पनांचा वापर अॅडम बॅकच्या संगणकीय दृष्ट्या कठीण हॅशकॅश पझल्ससोबत क्रिप्टोकरन्सीसाठी एक संकल्पना तयार करण्यासाठी करते, परंतु पुन्हा एकदा बॅकएंड म्हणून विश्वसनीय संगणनावर अवलंबून राहिल्याने ती आदर्श ठरली नाही. 2009 मध्ये, सातोशी नाकामोटो यांनी प्रथमच व्यवहारात एक विकेंद्रित चलन लागू केले, ज्यात सार्वजनिक की क्रिप्टोग्राफीद्वारे मालकी व्यवस्थापित करण्यासाठी स्थापित प्रिमिटिव्हजला, नाण्यांचा मालक कोण आहे याचा मागोवा ठेवण्यासाठी एका सहमती अल्गोरिदमसह, ज्याला "प्रूफ-ऑफ-वर्क" म्हणून ओळखले जाते, जोडले गेले.

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

बिटकॉइन एक स्टेट ट्रान्झिशन प्रणाली म्हणून

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

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

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

APPLY({ एलिस: $50, बॉब: $50 },"एलिसकडून बॉबला $20 पाठवा") = { एलिस: $30, बॉब: $70 }

परंतु:

APPLY({ एलिस: $50, बॉब: $50 },"एलिसकडून बॉबला $70 पाठवा") = 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 "चेंज" असेल, ज्याची मालक स्वतः एलिस असेल.

मायनिंग

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

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

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

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

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

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

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

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

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

मर्कल ट्रीज

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

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

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

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

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

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

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

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

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

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

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

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

• ट्युरिंग-कंप्लीटनेसचा अभाव - म्हणजेच, बिटकॉइन स्क्रिप्टिंग भाषा संगणनाच्या मोठ्या उपसंचला समर्थन देत असली तरी, ती जवळजवळ सर्व गोष्टींना समर्थन देत नाही. मुख्य श्रेणी जी गहाळ आहे ती म्हणजे लूप्स. हे व्यवहार पडताळणीदरम्यान अनंत लूप टाळण्यासाठी केले जाते; सैद्धांतिकदृष्ट्या हे स्क्रिप्ट प्रोग्रॅमर्ससाठी एक मात करता येण्याजोगा अडथळा आहे, कारण कोणताही लूप फक्त अंतर्निहित कोडला if स्टेटमेंटसह अनेक वेळा पुनरावृत्त करून अनुकरण केला जाऊ शकतो, परंतु यामुळे अशा स्क्रिप्ट्स तयार होतात ज्या खूप जागा-अकार्यक्षम असतात. उदाहरणार्थ, पर्यायी इलिप्टिक कर्व स्वाक्षरी अल्गोरिदम लागू करण्यासाठी संभाव्यतः 256 पुनरावृत्त गुणाकार फेऱ्या आवश्यक असतील ज्या सर्व वैयक्तिकरित्या कोडमध्ये समाविष्ट असतील.
• मूल्य-अंधत्व - काढल्या जाऊ शकणाऱ्या रकमेवर सूक्ष्म-नियंत्रण प्रदान करण्यासाठी UTXO स्क्रिप्टसाठी कोणताही मार्ग नाही. उदाहरणार्थ, ओरॅकल कॉन्ट्रॅक्टचा एक शक्तिशाली वापर म्हणजे हेजिंग कॉन्ट्रॅक्ट, जिथे A आणि B $1000 किमतीचे BTC टाकतात आणि 30 दिवसांनंतर स्क्रिप्ट $1000 किमतीचे BTC A ला पाठवते आणि उर्वरित B ला. यासाठी 1 BTC चे USD मधील मूल्य निश्चित करण्यासाठी ओरॅकलची आवश्यकता असेल, परंतु तरीही सध्या उपलब्ध असलेल्या पूर्णपणे केंद्रीकृत उपायांच्या तुलनेत विश्वास आणि पायाभूत सुविधांच्या गरजेच्या बाबतीत ही एक मोठी सुधारणा आहे. तथापि, UTXO हे सर्व किंवा काहीच नसल्यामुळे, हे साध्य करण्याचा एकमेव मार्ग म्हणजे विविध मूल्यांचे अनेक UTXO (उदा. ३० पर्यंतच्या प्रत्येक k साठी २^k चा एक UTXO) असणे आणि कोणत्या UTXO ला A कडे आणि कोणत्या B कडे पाठवायचे हे निवडण्यासाठी ओरॅकलचा वापर करणे हा एक अत्यंत अकार्यक्षम हॅक आहे.
• स्थितीचा अभाव - UTXO खर्च केले जाऊ शकतात किंवा खर्च न केलेले असू शकतात; बहु-स्तरीय करार किंवा स्क्रिप्ट्ससाठी कोणतीही संधी नाही जी त्यापलीकडे कोणतीही अन्य अंतर्गत स्थिती ठेवतात. यामुळे बहु-स्तरीय पर्याय करार, विकेंद्रित एक्सचेंज ऑफर्स किंवा द्वि-स्तरीय क्रिप्टोग्राफिक कमिटमेंट प्रोटोकॉल (सुरक्षित संगणकीय बक्षिसांसाठी आवश्यक) बनवणे कठीण होते. याचा अर्थ असाही आहे की UTXO चा वापर फक्त साधे, एक-वेळचे करार तयार करण्यासाठी केला जाऊ शकतो आणि विकेंद्रित संस्थांसारख्या अधिक गुंतागुंतीच्या "स्टेटफुल" करारांसाठी नाही, आणि मेटा-प्रोटोकॉल लागू करणे कठीण करते. बायनरी स्थिती आणि मूल्य-अंधत्व यांचे संयोजन याचा अर्थ असाही आहे की दुसरा महत्त्वाचा अनुप्रयोग, काढण्याची मर्यादा, अशक्य आहे.
• ब्लॉकचेन-अंधत्व - UTXO ब्लॉकचेन डेटा जसे की नॉन्स, टाइमस्टँप आणि मागील ब्लॉक हॅशसाठी अंधळे आहेत. हे जुगारातील आणि इतर अनेक श्रेणींमधील अनुप्रयोगांना गंभीरपणे मर्यादित करते, स्क्रिप्टिंग भाषेला यादृच्छिकतेच्या संभाव्य मौल्यवान स्त्रोतापासून वंचित ठेवून.

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

Ethereum

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

इथेरियम खाती

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

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

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

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

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

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

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

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

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

संदेश

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

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

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

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

Ethereum स्टेट ट्रान्झिशन फंक्शन

Ethereum स्टेट ट्रान्झिशन फंक्शन, 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 दर्शवतात. या प्रकरणात स्टेट ट्रान्झिशन फंक्शनची प्रक्रिया खालीलप्रमाणे आहे:

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 ने G गॅससह B ला कॉल केले तर A च्या अंमलबजावणीत जास्तीत जास्त G गॅस गमावण्याची हमी असते. शेवटी, लक्षात घ्या की CREATE नावाचा एक ऑपकोड आहे, जो एक कॉन्ट्रॅक्ट तयार करतो; त्याचे अंमलबजावणी यांत्रिकी सामान्यतः CALL सारखेच आहेत, या अपवादासह की अंमलबजावणीचे आउटपुट नव्याने तयार केलेल्या कॉन्ट्रॅक्टचा कोड निर्धारित करते.

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

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

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

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

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

ब्लॉकचेन आणि मायनिंग

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

1. संदर्भित मागील ब्लॉक अस्तित्वात आहे आणि वैध आहे का ते तपासा.
2. ब्लॉकचा टाइमस्टॅम्प संदर्भित मागील ब्लॉकपेक्षा जास्त आहे आणि भविष्यात 15 मिनिटांपेक्षा कमी आहे का ते तपासा.
3. ब्लॉक क्रमांक, डिफिकल्टी, ट्रान्झॅक्शन रूट, अंकल रूट आणि गॅस लिमिट (विविध लो-लेव्हल Ethereum-विशिष्ट संकल्पना) वैध आहेत का ते तपासा.
4. ब्लॉकवरील प्रूफ-ऑफ-वर्क वैध आहे का ते तपासा.
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 स्टेटच्या मर्कल ट्री रूटची किंमत ब्लॉक हेडरमध्ये प्रदान केलेल्या अंतिम स्टेट रूटच्या समान आहे का ते तपासा. जर असेल, तर ब्लॉक वैध आहे; अन्यथा, तो वैध नाही.

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

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

ॲप्लिकेशन्स

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

टोकन सिस्टीम

ऑन-ब्लॉकचेन टोकन सिस्टीममध्ये अनेक ॲप्लिकेशन्स आहेत, ज्यात USD किंवा सोन्यासारख्या मालमत्तेचे प्रतिनिधित्व करणारे उप-चलन, कंपनीचे स्टॉक्स, स्मार्ट प्रॉपर्टीचे प्रतिनिधित्व करणारे वैयक्तिक टोकन, सुरक्षित बनावट-नसलेले कूपन आणि अगदी पारंपारिक मूल्याशी अजिबात संबंध नसलेले टोकन सिस्टीम यांचा समावेश आहे, जे प्रोत्साहनासाठी पॉइंट सिस्टीम म्हणून वापरले जातात. टोकन सिस्टीम Ethereum मध्ये आश्चर्यकारकपणे सोप्या आहेत. समजून घेण्याचा मुख्य मुद्दा हा आहे की चलन, किंवा टोकन सिस्टीम, मूलतः एक डेटाबेस आहे ज्यात एकच ऑपरेशन आहे: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

DAO कोड कसा करायचा याची एक सामान्य रूपरेषा खालीलप्रमाणे आहे. सर्वात सोपी रचना म्हणजे फक्त एक स्व-बदलणारा कोडचा तुकडा जो दोन तृतीयांश सदस्य बदलावर सहमत झाल्यास बदलतो. जरी कोड सैद्धांतिकदृष्ट्या अपरिवर्तनीय असला तरी, कोडचे तुकडे वेगळ्या कॉन्ट्रॅक्टमध्ये ठेवून आणि कोणत्या कॉन्ट्रॅक्टला कॉल करायचे याचा पत्ता बदलण्यायोग्य स्टोरेजमध्ये संग्रहित करून यावर सहज मात करता येते आणि वास्तविक परिवर्तनीयता मिळवता येते. अशा 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 ला विकेंद्रित समुदाय म्हणून सेंद्रियपणे वाढण्यास अनुमती देईल, ज्यामुळे लोकांना अखेरीस सदस्य कोण आहे हे फिल्टर करण्याचे काम तज्ञांना सोपवता येईल, जरी "सध्याच्या प्रणाली" च्या विपरीत तज्ञ सहजपणे अस्तित्वात येऊ आणि जाऊ शकतात कारण वैयक्तिक समुदाय सदस्य त्यांचे संरेखन बदलतात.

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

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

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

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

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

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

३. एक विकेंद्रित डेटा फीड**. फरकासाठीच्या आर्थिक करारांसाठी, 'शेलिंगकॉइनopens in a new tab' नावाच्या प्रोटोकॉलद्वारे डेटा फीडचे विकेंद्रीकरण करणे शक्य आहे. शेलिंगकॉइन मुळात खालीलप्रमाणे कार्य करते: N पक्ष सर्व एका दिलेल्या डेटाचे मूल्य (उदा. ETH/USD किंमत) प्रणालीमध्ये टाकतात, मूल्यांची क्रमवारी लावली जाते, आणि २५ व्या ते ७५ व्या पर्सेंटाइलमधील प्रत्येकाला बक्षीस म्हणून एक टोकन मिळतो. प्रत्येकाला तेच उत्तर देण्यास प्रोत्साहन आहे जे इतर सर्व देतील, आणि मोठ्या संख्येने खेळाडू ज्या एकमेव मूल्यावर वास्तविकपणे सहमत होऊ शकतात ते म्हणजे स्पष्ट डीफॉल्ट: सत्य. हे एक विकेंद्रित प्रोटोकॉल तयार करते जे सैद्धांतिकदृष्ट्या कोणतीही संख्या मूल्ये प्रदान करू शकते, ज्यात ETH/USD किंमत, बर्लिनमधील तापमान किंवा अगदी एखाद्या विशिष्ट कठीण गणनेचा परिणाम यांचा समावेश आहे.

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

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

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

7. अंदाज बाजार. ओरॅकल किंवा शेलिंगकोइन प्रदान केल्यास, भविष्यवाणी बाजारांची अंमलबजावणी करणे देखील सोपे आहे, आणि शेलिंगकोइनसह भविष्यवाणी बाजार विकेंद्रित संस्थांसाठी शासन प्रोटोकॉल म्हणून फ्युटार्कीopens in a new tab चे पहिले मुख्य प्रवाहातील ऍप्लिकेशन सिद्ध होऊ शकते.

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

विविध आणि चिंता

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

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

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

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

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

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

शुल्क

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

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

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) ही मुख्य समस्या आहे; ती सोडवण्यासाठी आम्ही फक्त एक फ्लोटिंग कॅप स्थापित करतो: कोणत्याही ब्लॉकमध्ये 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 वर सेट केलेले स्थिरांक आहेत, परंतु पुढील विश्लेषणानंतर ते बदलले जाण्याची शक्यता आहे.

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

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

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

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

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

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

C0: call(C1); call(C1);
C1: call(C2); call(C2);
C2: call(C3); call(C3);
...
C49: call(C50); call(C50);
C50: (एका प्रोग्रामची एक स्टेप चालवा आणि स्टोरेजमधील बदल रेकॉर्ड करा)

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

चलन आणि जारी करणे

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

• 1: wei
• 10¹²: szabo
• 10¹⁵: finney
• 10¹⁸: इथर

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

जारी करण्याचे मॉडेल खालीलप्रमाणे असेल:

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

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

रैखिक चलन जारी असूनही, Bitcoin प्रमाणेच कालांतराने पुरवठा वाढीचा दर शून्याकडे झुकतो.

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

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

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

मायनिंग केंद्रीकरण

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

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

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

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

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

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

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

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

निष्कर्ष

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

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

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

टीपा

1. एका जाणकार वाचकाच्या लक्षात येईल की वास्तविक, बिटकॉइन ॲड्रेस हा इलिप्टिक कर्व्ह पब्लिक की चा हॅश असतो, आणि ती स्वतः पब्लिक की नसते. तथापि, पबकी हॅशला स्वतः पब्लिक की म्हणून संबोधणे हे क्रिप्टोग्राफिक पारिभाषिक शब्दावलीनुसार पूर्णपणे कायदेशीर आहे. याचे कारण असे की बिटकॉइनची क्रिप्टोग्राफी ही एक कस्टम डिजिटल सिग्नेचर अल्गोरिदम मानली जाऊ शकते, जिथे पब्लिक की मध्ये ECC पबकीचा हॅश असतो, स्वाक्षरीमध्ये ECC पबकी आणि ECC स्वाक्षरी जोडलेली असते आणि सत्यापन अल्गोरिदममध्ये स्वाक्षरीमधील ECC पबकीची तुलना पब्लिक की म्हणून प्रदान केलेल्या ECC पबकी हॅशशी केली जाते आणि नंतर ECC स्वाक्षरी ECC पबकीच्या विरोधात सत्यापित केली जाते.
2. तांत्रिकदृष्ट्या, मागील ११ ब्लॉक्सचे मध्यक.
3. अंतर्गत, २ आणि "CHARLIE" हे दोन्ही अंक आहेत^fn3, ज्यातील नंतरचा बिग-एंडियन बेस २५६ प्रतिनिधीत्वात आहे. अंक किमान ० आणि कमाल २^२५६-१ असू शकतात.

अधिक वाचन

1. आंतरिक मूल्यopens in a new tab
2. स्मार्ट प्रॉपर्टीopens in a new tab
3. स्मार्ट कॉन्ट्रॅक्ट्सopens in a new tab
4. बी-मनीopens in a new tab
5. पुन्हा वापरण्यायोग्य प्रूफ ऑफ वर्कopens in a new tab
6. मालकाच्या अधिकारासह सुरक्षित मालमत्ता शीर्षकopens in a new tab
7. बिटकॉइन व्हाइटपेपरopens in a new tab
8. नेमकोइन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. GHOSTopens 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 पहा.

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

पृष्ठ अखेरचे अद्यतन: १६ फेब्रुवारी, २०२६

popens in a new tab

mopens in a new tab

wopens in a new tab

+11

योगदानकर्ता पहा