diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..752357d3724 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "प्रमाणीकरणे" +description: "प्रूफ-ऑफ-स्टेक Ethereum वरील प्रमाणीकरणांचे वर्णन." +lang: mr +--- + +प्रत्येक इपॉकमध्ये व्हॅलिडेटरने प्रमाणीकरण तयार करणे, त्यावर स्वाक्षरी करणे आणि ते प्रसारित करणे अपेक्षित आहे. हे पृष्ठ या प्रमाणीकरणांचे स्वरूप, त्यांच्यावर कशी प्रक्रिया केली जाते आणि एकमत क्लायंटमध्ये ते कसे संप्रेषित केले जातात याची रूपरेषा देते. + +## प्रमाणीकरण म्हणजे काय? {#what-is-an-attestation} + +प्रत्येक [इपॉक](/glossary/#epoch) (6.4 मिनिटे) एक व्हॅलिडेटर नेटवर्कवर प्रमाणीकरणाचा प्रस्ताव देतो. प्रमाणीकरण हे इपॉकमधील एका विशिष्ट स्लॉटसाठी असते. प्रमाणीकरणाचा उद्देश व्हॅलिडेटरच्या साखळीबद्दलच्या दृष्टिकोनाच्या बाजूने मतदान करणे हा आहे, विशेषतः सर्वात अलीकडील जस्टिफाईड ब्लॉक आणि सध्याच्या इपॉकमधील पहिला ब्लॉक (ज्यांना `source` आणि `target` चेकपॉइंट म्हणून ओळखले जाते). ही माहिती सर्व सहभागी व्हॅलिडेटरसाठी एकत्रित केली जाते, ज्यामुळे नेटवर्कला ब्लॉकचेनच्या स्थितीबद्दल एकमतापर्यंत पोहोचता येते. + +प्रमाणीकरणामध्ये खालील घटक असतात: + +- `aggregation_bits`: व्हॅलिडेटरची एक बिटलिस्ट जिथे स्थिती त्यांच्या समितीमधील व्हॅलिडेटर निर्देशांकाशी जुळते; मूल्य (0/1) हे दर्शवते की व्हॅलिडेटरने `data` वर स्वाक्षरी केली आहे की नाही (म्हणजे, ते सक्रिय आहेत आणि ब्लॉक प्रस्तावकशी सहमत आहेत की नाही). +- `data`: खाली परिभाषित केल्यानुसार प्रमाणीकरणाशी संबंधित तपशील +- `signature`: एक BLS स्वाक्षरी जी वैयक्तिक व्हॅलिडेटरच्या स्वाक्षऱ्या एकत्रित करते + +प्रमाणीकरण करणाऱ्या व्हॅलिडेटरसाठी `data` तयार करणे हे पहिले कार्य आहे. `data` मध्ये खालील माहिती असते: + +- `slot`: स्लॉट क्रमांक ज्याचा प्रमाणीकरण संदर्भ देते +- `index`: एक क्रमांक जो ओळखतो की व्हॅलिडेटर दिलेल्या स्लॉटमध्ये कोणत्या समितीचा सदस्य आहे +- `beacon_block_root`: साखळीच्या सुरुवातीला व्हॅलिडेटरला दिसणाऱ्या ब्लॉकचा रूट हॅश (फोर्क-चॉइस अल्गोरिदम लागू करण्याचा परिणाम) +- `source`: फायनॅलिटी मताचा भाग जो दर्शवितो की व्हॅलिडेटर सर्वात अलीकडील जस्टिफाईड ब्लॉक म्हणून काय पाहतात +- `target`: फायनॅलिटी मताचा भाग जो दर्शवितो की व्हॅलिडेटर सध्याच्या इपॉकमधील पहिला ब्लॉक म्हणून काय पाहतात + +`data` तयार झाल्यावर, व्हॅलिडेटर `aggregation_bits` मधील त्यांच्या स्वतःच्या व्हॅलिडेटर निर्देशांकाशी संबंधित बिट 0 वरून 1 वर फ्लिप करू शकतो, हे दर्शवण्यासाठी की त्यांनी सहभाग घेतला आहे. + +शेवटी, व्हॅलिडेटर प्रमाणीकरणावर स्वाक्षरी करतो आणि ते नेटवर्कवर प्रसारित करतो. + +### एकत्रित प्रमाणीकरण {#aggregated-attestation} + +प्रत्येक व्हॅलिडेटरसाठी नेटवर्कवर हा डेटा प्रसारित करण्याशी संबंधित एक मोठा ओव्हरहेड आहे. म्हणून, वैयक्तिक व्हॅलिडेटरकडून आलेली प्रमाणीकरणे अधिक व्यापकपणे प्रसारित करण्यापूर्वी सबनेटमध्ये एकत्रित केली जातात. यामध्ये स्वाक्षऱ्या एकत्र करणे समाविष्ट आहे जेणेकरून प्रसारित होणाऱ्या प्रमाणीकरणामध्ये एकमत `data` आणि त्या `data` शी सहमत असलेल्या सर्व व्हॅलिडेटरच्या स्वाक्षऱ्या एकत्र करून तयार केलेली एकच स्वाक्षरी समाविष्ट असेल. हे `aggregation_bits` वापरून तपासले जाऊ शकते कारण हे प्रत्येक व्हॅलिडेटरचा त्यांच्या समितीमधील निर्देशांक (ज्याचा आयडी `data` मध्ये दिलेला आहे) प्रदान करते, जो वैयक्तिक स्वाक्षऱ्यांची चौकशी करण्यासाठी वापरला जाऊ शकतो. + +प्रत्येक इपॉकमध्ये प्रत्येक सबनेटमधील 16 व्हॅलिडेटर `एग्रीगेटर` म्हणून निवडले जातात. एग्रीगेटर गॉसिप नेटवर्कवर ऐकलेली सर्व प्रमाणीकरणे गोळा करतात ज्यात त्यांच्या स्वतःच्या प्रमाणीकरणासारखाच `data` असतो. प्रत्येक जुळणाऱ्या प्रमाणीकरणाच्या प्रेषकाची नोंद `aggregation_bits` मध्ये केली जाते. त्यानंतर एग्रीगेटर प्रमाणीकरण एकत्रित करून व्यापक नेटवर्कवर प्रसारित करतात. + +जेव्हा एखाद्या व्हॅलिडेटरची ब्लॉक प्रस्तावक म्हणून निवड केली जाते, तेव्हा ते सबनेटमधून आलेली एकत्रित प्रमाणीकरणे नवीन ब्लॉकमधील नवीनतम स्लॉटपर्यंत पॅकेज करतात. + +### प्रमाणीकरण समावेशाचे जीवनचक्र {#attestation-inclusion-lifecycle} + +1. निर्मिती +2. प्रसार +3. एकत्रीकरण +4. प्रसार +5. समावेश + +प्रमाणीकरणाचे जीवनचक्र खालील आराखड्यात स्पष्ट केले आहे: + +![प्रमाणीकरण जीवनचक्र](./attestation_schematic.png) + +## पुरस्कार {#rewards} + +प्रमाणीकरणे सादर केल्याबद्दल व्हॅलिडेटरना रिवॉर्ड दिले जातात. प्रमाणीकरणाचा रिवॉर्ड सहभागाचे ध्वज (स्रोत, लक्ष्य आणि हेड), बेस रिवॉर्ड आणि सहभागाचा दर यावर अवलंबून असतो. + +सादर केलेल्या प्रमाणीकरणावर आणि त्याच्या समावेशातील विलंबावर अवलंबून, प्रत्येक सहभाग ध्वज सत्य किंवा असत्य असू शकतो. + +सर्वोत्तम परिस्थिती तेव्हा उद्भवते जेव्हा तिन्ही ध्वज सत्य असतात, अशा परिस्थितीत व्हॅलिडेटरला (प्रत्येक योग्य ध्वजासाठी) कमाई होईल: + +`रिवॉर्ड += बेस रिवॉर्ड * ध्वज वजन * ध्वज प्रमाणीकरण दर / 64` + +ध्वज प्रमाणीकरण दर, दिलेल्या ध्वजासाठी सर्व प्रमाणीकरण करणाऱ्या व्हॅलिडेटरच्या प्रभावी बॅलन्सच्या बेरजेचा वापर करून, एकूण सक्रिय प्रभावी बॅलन्सच्या तुलनेत मोजला जातो. + +### बेस रिवॉर्ड {#base-reward} + +बेस रिवॉर्डची गणना प्रमाणीकरण करणाऱ्या व्हॅलिडेटरच्या संख्येनुसार आणि त्यांच्या प्रभावी स्टेक केलेल्या इथर बॅलन्सनुसार केली जाते: + +`बेस रिवॉर्ड = व्हॅलिडेटर प्रभावी बॅलन्स x 2^6 / SQRT(सर्व सक्रिय व्हॅलिडेटरचा प्रभावी बॅलन्स)` + +#### समावेशातील विलंब {#inclusion-delay} + +ज्यावेळी व्हॅलिडेटरनी साखळीच्या हेडवर (`ब्लॉक n`) मतदान केले, त्यावेळी `ब्लॉक n+1` अजून प्रस्तावित झाला नव्हता. म्हणून प्रमाणीकरणे नैसर्गिकरित्या **एक ब्लॉक नंतर** समाविष्ट होतात, त्यामुळे `ब्लॉक n` ला साखळीचे हेड म्हणून मतदान करणारी सर्व प्रमाणीकरणे `ब्लॉक n+1` मध्ये समाविष्ट होतात आणि **समावेशातील विलंब** 1 असतो. जर समावेशातील विलंब दुप्पट होऊन दोन स्लॉट झाला, तर प्रमाणीकरणाचा रिवॉर्ड अर्धा होतो, कारण प्रमाणीकरणाचा रिवॉर्ड मोजण्यासाठी बेस रिवॉर्डला समावेशातील विलंबाच्या व्युत्क्रमाने गुणले जाते. + +### प्रमाणीकरणाच्या परिस्थिती {#attestation-scenarios} + +#### मतदान करणारा व्हॅलिडेटर गहाळ {#missing-voting-validator} + +व्हॅलिडेटरकडे त्यांचे प्रमाणीकरण सादर करण्यासाठी जास्तीत जास्त 1 इपॉक असतो. जर इपॉक 0 मध्ये प्रमाणीकरण चुकले, तर ते इपॉक 1 मध्ये समावेशातील विलंबासह सादर करू शकतात. + +#### एग्रीगेटर गहाळ {#missing-aggregator} + +एकूण प्रति इपॉक 16 एग्रीगेटर असतात. याव्यतिरिक्त, यादृच्छिक व्हॅलिडेटर **256 इपॉकसाठी दोन सबनेट** चे सदस्यत्व घेतात आणि एग्रीगेटर गहाळ झाल्यास बॅकअप म्हणून काम करतात. + +#### ब्लॉक प्रस्तावक गहाळ {#missing-block-proposer} + +लक्षात घ्या की काही प्रकरणांमध्ये एक भाग्यवान एग्रीगेटर ब्लॉक प्रस्तावक देखील बनू शकतो. जर ब्लॉक प्रस्तावक गहाळ झाल्यामुळे प्रमाणीकरण समाविष्ट झाले नाही, तर पुढील ब्लॉक प्रस्तावक ते एकत्रित प्रमाणीकरण उचलून पुढील ब्लॉकमध्ये समाविष्ट करेल. तथापि, **समावेशातील विलंब** एकाने वाढेल. + +## पुढील वाचन {#further-reading} + +- [विटालिकच्या एनोटेटेड एकमत स्पेकमधील प्रमाणीकरणे](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [eth2book.info मधील प्रमाणीकरणे](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..c011932b876 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "ब्लॉक प्रस्ताव" +description: "प्रूफ-ऑफ-स्टेक Ethereum मध्ये ब्लॉक कसे प्रस्तावित केले जातात याचे स्पष्टीकरण." +lang: mr +--- + +ब्लॉक हे ब्लॉकचेनचे मूलभूत एकक आहेत. ब्लॉक हे माहितीचे स्वतंत्र एकक आहेत जे नोड्स दरम्यान दिले जातात, त्यावर सहमती दर्शवली जाते आणि प्रत्येक नोडच्या डेटाबेसमध्ये जोडले जातात. हे पृष्ठ ते कसे तयार केले जातात हे स्पष्ट करते. + +## पूर्वतयारी {#prerequisites} + +ब्लॉक प्रस्ताव हा प्रूफ-ऑफ-स्टेक प्रोटोकॉलचा भाग आहे. हे पृष्ठ समजण्यास मदत होण्यासाठी, आम्ही शिफारस करतो की तुम्ही [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) आणि [ब्लॉक आर्किटेक्चर](/developers/docs/blocks/) बद्दल वाचा. + +## ब्लॉक कोण तयार करते? {#who-produces-blocks} + +व्हॅलिडेटर खाती ब्लॉक प्रस्तावित करतात. व्हॅलिडेटर खाती नोड ऑपरेटरद्वारे व्यवस्थापित केली जातात जे त्यांच्या एक्झिक्यूशन आणि कन्सेन्सस क्लायंटचा भाग म्हणून व्हॅलिडेटर सॉफ्टवेअर चालवतात आणि डिपॉझिट कॉन्ट्रॅक्टमध्ये किमान 32 ETH जमा केले आहेत. तथापि, प्रत्येक व्हॅलिडेटर केवळ अधूनमधून ब्लॉक प्रस्तावित करण्यासाठी जबाबदार असतो. Ethereum वेळेचे मोजमाप स्लॉट्स आणि इपॉक्समध्ये करते. प्रत्येक स्लॉट बारा सेकंदांचा असतो, आणि 32 स्लॉट्स (6.4 मिनिटे) मिळून एक इपॉक बनतो. प्रत्येक स्लॉट ही Ethereum वर नवीन ब्लॉक जोडण्याची एक संधी आहे. + +### यादृच्छिक निवड {#random-selection} + +प्रत्येक स्लॉटमध्ये ब्लॉक प्रस्तावित करण्यासाठी एका व्हॅलिडेटरची स्यूडो-रँडम पद्धतीने निवड केली जाते. ब्लॉकचेनमध्ये खऱ्या अर्थाने यादृच्छिकता अशी कोणतीही गोष्ट नाही कारण जर प्रत्येक नोडने खरोखर यादृच्छिक संख्या तयार केल्या, तर ते कन्सेन्ससवर येऊ शकणार नाहीत. त्याऐवजी, व्हॅलिडेटर निवड प्रक्रिया अनपेक्षित बनवणे हा उद्देश आहे. Ethereum वर RANDAO नावाच्या अल्गोरिदमचा वापर करून यादृच्छिकता प्राप्त केली जाते, जो ब्लॉक प्रस्तावकाकडून एक हॅश एका सीडसोबत मिसळतो जो प्रत्येक ब्लॉकवर अपडेट होतो. हे मूल्य एकूण व्हॅलिडेटर सेटमधून विशिष्ट व्हॅलिडेटर निवडण्यासाठी वापरले जाते. विशिष्ट प्रकारच्या सीड मॅनिप्युलेशनपासून संरक्षण करण्याचा एक मार्ग म्हणून व्हॅलिडेटर निवड दोन इपॉक्स आधीच निश्चित केली जाते. + +जरी व्हॅलिडेटर्स प्रत्येक स्लॉटमध्ये RANDAO मध्ये भर घालत असले तरी, जागतिक RANDAO मूल्य प्रत्येक इपॉकला फक्त एकदाच अपडेट केले जाते. पुढील ब्लॉक प्रस्तावकाचा निर्देशांक मोजण्यासाठी, प्रत्येक स्लॉटमध्ये एक अद्वितीय मूल्य देण्यासाठी RANDAO मूल्य स्लॉट क्रमांकासोबत मिसळले जाते. एका वैयक्तिक व्हॅलिडेटरच्या निवडीची संभाव्यता फक्त `1/N` नसते (जिथे `N` = एकूण सक्रिय व्हॅलिडेटर). त्याऐवजी, ते प्रत्येक व्हॅलिडेटरच्या प्रभावी ETH बॅलन्सनुसार भारित केले जाते. जास्तीत जास्त प्रभावी बॅलन्स 32 ETH आहे (याचा अर्थ `बॅलन्स < 32 ETH` मुळे `बॅलन्स == 32 ETH` पेक्षा कमी वजन मिळते, परंतु `बॅलन्स > 32 ETH` मुळे `बॅलन्स == 32 ETH` पेक्षा जास्त वजन मिळत नाही). + +प्रत्येक स्लॉटमध्ये फक्त एक ब्लॉक प्रस्तावक निवडला जातो. सामान्य परिस्थितीत, एकच ब्लॉक निर्माता त्यांच्या समर्पित स्लॉटमध्ये एकच ब्लॉक तयार करतो आणि रिलीज करतो. एकाच स्लॉटसाठी दोन ब्लॉक तयार करणे हा एक स्लॅशेबल गुन्हा आहे, ज्याला अनेकदा "इक्विवोकेशन" म्हणून ओळखले जाते. + +## ब्लॉक कसा तयार केला जातो? {#how-is-a-block-created} + +ब्लॉक प्रस्तावकाने त्यांच्या स्वतःच्या स्थानिकरित्या चालवलेल्या फोर्क चॉईस अल्गोरिदमच्या दृष्टिकोनानुसार, चेनमधील सर्वात अलीकडील हेडच्या वर तयार होणारा एक स्वाक्षरी केलेला बीकन ब्लॉक ब्रॉडकास्ट करणे अपेक्षित आहे. फोर्क चॉईस अल्गोरिदम मागील स्लॉटमधून उरलेली कोणतीही रांगेतील ॲटेस्टेशन्स लागू करतो, नंतर त्याच्या इतिहासामध्ये ॲटेस्टेशन्सचे सर्वाधिक संचित वजन असलेला ब्लॉक शोधतो. तो ब्लॉक प्रस्तावकाने तयार केलेल्या नवीन ब्लॉकचा पॅरेंट आहे. + +ब्लॉक प्रस्तावक त्याच्या स्वतःच्या स्थानिक डेटाबेस आणि चेनच्या दृश्यातून डेटा गोळा करून एक ब्लॉक तयार करतो. ब्लॉकची सामग्री खालील स्निपेटमध्ये दर्शविली आहे: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +`randao_reveal` फील्ड एक सत्यापित करण्यायोग्य यादृच्छिक मूल्य घेते जे ब्लॉक प्रस्तावक सध्याच्या इपॉक क्रमांकावर स्वाक्षरी करून तयार करतो. `eth1_data` हे डिपॉझिट कॉन्ट्रॅक्टच्या ब्लॉक प्रस्तावकाच्या दृष्टिकोनासाठी एक मत आहे, ज्यामध्ये डिपॉझिट मर्केल ट्राईचे रूट आणि नवीन डिपॉझिट सत्यापित करण्यास सक्षम करणाऱ्या डिपॉझिटची एकूण संख्या समाविष्ट आहे. `graffiti` हे एक ऐच्छिक फील्ड आहे ज्याचा वापर ब्लॉकवर संदेश जोडण्यासाठी केला जाऊ शकतो. `proposer_slashings` आणि `attester_slashings` ही अशी फील्ड्स आहेत ज्यात प्रस्तावकाच्या चेनच्या दृष्टिकोनानुसार, विशिष्ट व्हॅलिडेटर्सनी स्लॅशेबल गुन्हे केल्याचा पुरावा असतो. `deposits` ही नवीन व्हॅलिडेटर डिपॉझिटची एक यादी आहे ज्याबद्दल ब्लॉक प्रस्तावकाला माहिती आहे, आणि `voluntary_exits` ही अशा व्हॅलिडेटर्सची यादी आहे जे बाहेर पडू इच्छितात आणि ज्यांच्याबद्दल ब्लॉक प्रस्तावकाने कन्सेन्सस लेयर गॉसिप नेटवर्कवर ऐकले आहे. `sync_aggregate` हा एक वेक्टर आहे जो दाखवतो की कोणते व्हॅलिडेटर पूर्वी सिंक कमिटीला (लाईट क्लायंट डेटा देणाऱ्या व्हॅलिडेटर्सचा एक उपसंच) नियुक्त केले होते आणि डेटा स्वाक्षरी करण्यात सहभागी झाले होते. + +`execution_payload` एक्झिक्यूशन आणि कन्सेन्सस क्लायंट्समध्ये व्यवहारांविषयी माहिती पास करण्यास सक्षम करते. `execution_payload` हा एक्झिक्यूशन डेटाचा एक ब्लॉक आहे जो बीकन ब्लॉकमध्ये नेस्ट केला जातो. `execution_payload` मधील फील्ड्स Ethereum यलो पेपरमध्ये वर्णन केलेल्या ब्लॉक रचनेला प्रतिबिंबित करतात, फक्त त्यात कोणतेही ओमर्स नाहीत आणि `difficulty` च्या जागी `prev_randao` अस्तित्वात आहे. एक्झिक्यूशन क्लायंटला व्यवहारांच्या स्थानिक पूलमध्ये प्रवेश असतो, ज्याबद्दल त्याने स्वतःच्या गॉसिप नेटवर्कवर ऐकले आहे. हे व्यवहार पोस्ट-स्टेट म्हणून ओळखले जाणारे अपडेटेड स्टेट ट्राई तयार करण्यासाठी स्थानिकरित्या कार्यान्वित केले जातात. हे व्यवहार `transactions` नावाच्या यादीच्या स्वरूपात `execution_payload` मध्ये समाविष्ट केले जातात आणि पोस्ट-स्टेट `state-root` फील्डमध्ये प्रदान केले जाते. + +हा सर्व डेटा एका बीकन ब्लॉकमध्ये गोळा केला जातो, त्यावर स्वाक्षरी केली जाते, आणि ब्लॉक प्रस्तावकाच्या पिअर्सना प्रसारित केला जातो, जे तो त्यांच्या पिअर्सना पुढे पाठवतात, इत्यादी. + +[ब्लॉक्सची रचना](/developers/docs/blocks) याबद्दल अधिक वाचा. + +## ब्लॉकचे काय होते? {#what-happens-to-blocks} + +ब्लॉक प्रस्तावकाच्या स्थानिक डेटाबेसमध्ये ब्लॉक जोडला जातो आणि कन्सेन्सस लेयर गॉसिप नेटवर्कद्वारे पिअर्सना प्रसारित केला जातो. जेव्हा एका व्हॅलिडेटरला ब्लॉक मिळतो, तेव्हा तो त्यातील डेटा सत्यापित करतो, ज्यामध्ये ब्लॉकला योग्य पॅरेंट आहे की नाही, तो योग्य स्लॉटशी संबंधित आहे की नाही, प्रस्तावकाचा निर्देशांक अपेक्षित आहे की नाही, RANDAO रिव्हील वैध आहे की नाही आणि प्रस्तावकाला स्लॅश केलेले नाही हे तपासणे समाविष्ट आहे. `execution_payload` अनबंडल केले जाते, आणि प्रस्तावित स्टेट बदल तपासण्यासाठी व्हॅलिडेटरचा एक्झिक्यूशन क्लायंट यादीतील व्यवहार पुन्हा कार्यान्वित करतो. ब्लॉक या सर्व तपासण्या पास करतो असे गृहीत धरून, प्रत्येक व्हॅलिडेटर तो ब्लॉक त्याच्या स्वतःच्या कॅनोनिकल चेनमध्ये जोडतो. पुढील स्लॉटमध्ये ही प्रक्रिया पुन्हा सुरू होते. + +## ब्लॉक रिवॉर्ड्स {#block-rewards} + +ब्लॉक प्रस्तावकाला त्यांच्या कामासाठी पेमेंट मिळते. एक `base_reward` आहे जो सक्रिय व्हॅलिडेटर्सची संख्या आणि त्यांच्या प्रभावी बॅलन्सचे कार्य म्हणून मोजला जातो. ब्लॉक प्रस्तावकाला नंतर ब्लॉकमध्ये समाविष्ट असलेल्या प्रत्येक वैध ॲटेस्टेशनसाठी `base_reward` चा एक अंश मिळतो; जितके जास्त व्हॅलिडेटर ब्लॉकला ॲटेस्ट करतात, तितके ब्लॉक प्रस्तावकाचे रिवॉर्ड जास्त असते. ज्या व्हॅलिडेटर्सना स्लॅश केले पाहिजे त्यांची तक्रार करण्यासाठी देखील एक रिवॉर्ड आहे, जे प्रत्येक स्लॅश केलेल्या व्हॅलिडेटरसाठी `1/512 * प्रभावी बॅलन्स` च्या बरोबरीचे आहे. + +[रिवॉर्ड्स आणि दंड यावर अधिक](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## पुढील वाचन {#further-reading} + +- [ब्लॉक्सची ओळख](/developers/docs/blocks/) +- [Proof-of-stake चा परिचय](/developers/docs/consensus-mechanisms/pos/) +- [Ethereum कन्सेन्सस स्पेक्स](https://github.com/ethereum/consensus-specs) +- [Gasper ची ओळख](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Ethereum अपग्रेड करणे](https://eth2book.info/) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..0d209bd0ed8 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "वारंवार विचारले जाणारे प्रश्न" +description: "प्रूफ-ऑफ-स्टेक Ethereum वर वारंवार विचारले जाणारे प्रश्न." +lang: mr +--- + +## प्रूफ-ऑफ-स्टेक म्हणजे काय? {#what-is-proof-of-stake} + +प्रूफ-ऑफ-स्टेक हा अल्गोरिदमचा एक वर्ग आहे जो ब्लॉकचेनला सुरक्षा प्रदान करू शकतो, हे सुनिश्चित करून की जे हल्लेखोर अप्रामाणिकपणे वागतात त्यांची मौल्यवान मालमत्ता गमावली जाते. प्रूफ-ऑफ-स्टेक सिस्टीममध्ये व्हॅलिडेटर्सच्या एका सेटची आवश्यकता असते जे काही मालमत्ता उपलब्ध करतात, जी व्हॅलिडेटरने काही सिद्ध करण्यायोग्य अप्रामाणिक वर्तनात गुंतल्यास नष्ट केली जाऊ शकते. Ethereum ब्लॉकचेन सुरक्षित करण्यासाठी प्रूफ-ऑफ-स्टेक यंत्रणा वापरते. + +## प्रूफ-ऑफ-स्टेकची प्रूफ-ऑफ-वर्कशी तुलना कशी होते? {#comparison-to-proof-of-work} + +प्रूफ-ऑफ-वर्क आणि प्रूफ-ऑफ-स्टेक या दोन्ही यंत्रणा आहेत ज्या दुर्भावनापूर्ण कलाकारांना नेटवर्कवर स्पॅमिंग किंवा फसवणूक करण्यापासून आर्थिकदृष्ट्या परावृत्त करतात. दोन्ही प्रकरणांमध्ये, जे नोड्स सहमतीमध्ये सक्रियपणे भाग घेतात ते काही मालमत्ता "नेटवर्कमध्ये" ठेवतात, जी ते गैरवर्तन केल्यास गमावतील. + +प्रूफ-ऑफ-वर्कमध्ये, ही मालमत्ता ऊर्जा आहे. नोड, ज्याला मायनर म्हणून ओळखले जाते, एक अल्गोरिदम चालवतो ज्याचा उद्देश इतर कोणत्याही नोडपेक्षा वेगाने मूल्य मोजणे आहे. सर्वात वेगवान नोडला चेनमध्ये ब्लॉक प्रस्तावित करण्याचा अधिकार आहे. चेनचा इतिहास बदलण्यासाठी किंवा ब्लॉक प्रस्तावावर वर्चस्व गाजवण्यासाठी, मायनरकडे इतकी संगणकीय शक्ती असणे आवश्यक आहे की ते नेहमीच शर्यत जिंकतील. हे अत्यंत महाग आणि अंमलात आणण्यास कठीण आहे, ज्यामुळे चेनचे हल्ल्यांपासून संरक्षण होते. प्रूफ-ऑफ-वर्क वापरून "माइन" करण्यासाठी लागणारी ऊर्जा ही एक वास्तविक-जगातील मालमत्ता आहे ज्यासाठी मायनर्स पैसे देतात. + +प्रूफ-ऑफ-स्टेकसाठी नोड्स, ज्यांना व्हॅलिडेटर्स म्हणून ओळखले जाते, यांनी स्पष्टपणे एक क्रिप्टो मालमत्ता स्मार्ट कॉन्ट्रॅक्टमध्ये सबमिट करणे आवश्यक आहे. जर व्हॅलिडेटरने गैरवर्तन केले, तर ही क्रिप्टो नष्ट केली जाऊ शकते कारण ते ऊर्जा खर्चाद्वारे अप्रत्यक्षपणे न करता थेट चेनमध्ये आपली मालमत्ता "स्टेकिंग" करत आहेत. + +प्रूफ-ऑफ-वर्कमध्ये जास्त ऊर्जा लागते कारण मायनिंग प्रक्रियेत वीज वापरली जाते. दुसरीकडे, प्रूफ-ऑफ-स्टेकला खूप कमी ऊर्जेची आवश्यकता असते - Ethereum व्हॅलिडेटर्स अगदी Raspberry Pi सारख्या कमी-शक्तीच्या डिव्हाइसवर देखील चालू शकतात. Ethereumची प्रूफ-ऑफ-स्टेक यंत्रणा प्रूफ-ऑफ-वर्कपेक्षा अधिक सुरक्षित मानली जाते कारण हल्ला करण्याची किंमत जास्त आहे आणि हल्लेखोरासाठी त्याचे परिणाम अधिक गंभीर आहेत. + +प्रूफ-ऑफ-वर्क विरुद्ध प्रूफ-ऑफ-स्टेक हा एक वादग्रस्त विषय आहे. [विटालिक ब्युटेरिनचा ब्लॉग](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work) आणि जस्टिन ड्रेक आणि लिन आल्डन यांच्यातील वादविवाद युक्तिवादांचा चांगला सारांश देतात. + + + +## प्रूफ-ऑफ-स्टेक ऊर्जा-कार्यक्षम आहे का? {#is-pos-energy-efficient} + +होय. प्रूफ-ऑफ-स्टेक नेटवर्कवरील नोड्स खूप कमी प्रमाणात ऊर्जा वापरतात. एका तृतीय-पक्ष अभ्यासाने निष्कर्ष काढला आहे की संपूर्ण प्रूफ-ऑफ-स्टेक Ethereum नेटवर्क अंदाजे 0.0026 TWh/yr ऊर्जा वापरते - जे केवळ यूएसमधील गेमिंगपेक्षा सुमारे 13,000 पट कमी आहे. + +[Ethereum च्या ऊर्जा वापराविषयी अधिक](/energy-consumption/). + +## प्रूफ-ऑफ-स्टेक सुरक्षित आहे का? {#is-pos-secure} + +Ethereumचे प्रूफ-ऑफ-स्टेक खूप सुरक्षित आहे. ही यंत्रणा लाइव्ह होण्यापूर्वी आठ वर्षांहून अधिक काळ त्यावर कठोरपणे संशोधन, विकास आणि चाचणी केली गेली. सुरक्षेची हमी प्रूफ-ऑफ-वर्क ब्लॉकचेनपेक्षा वेगळी आहे. प्रूफ-ऑफ-स्टेकमध्ये, दुर्भावनापूर्ण व्हॅलिडेटर्सना सक्रियपणे शिक्षा दिली जाऊ शकते ("स्लॅश" केले जाऊ शकते) आणि व्हॅलिडेटर सेटमधून बाहेर काढले जाऊ शकते, ज्यामुळे मोठ्या प्रमाणात ETH चे नुकसान होते. प्रूफ-ऑफ-वर्क अंतर्गत, हल्लेखोर त्यांच्याकडे पुरेशी हॅश पॉवर असेपर्यंत त्यांचा हल्ला पुन्हा पुन्हा करत राहू शकतो. प्रूफ-ऑफ-वर्कपेक्षा प्रूफ-ऑफ-स्टेक Ethereum वर समकक्ष हल्ले करणे देखील अधिक महाग आहे. चेनच्या लाइव्हनेसवर परिणाम करण्यासाठी, नेटवर्कवरील एकूण स्टेक केलेल्या इथरपैकी किमान 33% आवश्यक आहे (अत्यंत कमी यशस्वीतेच्या शक्यतेसह खूप अत्याधुनिक हल्ल्यांची प्रकरणे वगळता). भविष्यातील ब्लॉक्सच्या सामग्रीवर नियंत्रण ठेवण्यासाठी, एकूण स्टेक केलेल्या ETH पैकी किमान 51% आवश्यक आहे आणि इतिहास पुन्हा लिहिण्यासाठी, एकूण स्टेकच्या 66% पेक्षा जास्त आवश्यक आहे. Ethereum प्रोटोकॉल 33% किंवा 51% हल्ल्याच्या परिस्थितीत या मालमत्ता नष्ट करेल आणि 66% हल्ल्याच्या परिस्थितीत सामाजिक सहमतीने नष्ट करेल. + +- [हल्लेखोरांपासून Ethereum प्रूफ-ऑफ-स्टेकचे संरक्षण करण्यावर अधिक](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [प्रूफ-ऑफ-स्टेक डिझाइनवर अधिक](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## प्रूफ-ऑफ-स्टेकमुळे Ethereum स्वस्त होते का? {#does-pos-make-ethereum-cheaper} + +नाही. व्यवहार पाठवण्याची किंमत (गॅस फी) डायनॅमिक फी मार्केटद्वारे निर्धारित केली जाते जी नेटवर्कची मागणी वाढल्यास वाढते. एकमत यंत्रणा यावर थेट प्रभाव टाकत नाही. + +[गॅसवर अधिक](/developers/docs/gas). + +## नोड्स, क्लायंट आणि व्हॅलिडेटर्स म्हणजे काय? {#what-are-nodes-clients-and-validators} + +नोड्स हे Ethereum नेटवर्कशी जोडलेले संगणक आहेत. क्लायंट हे सॉफ्टवेअर आहेत जे ते चालवतात जे संगणकाला नोडमध्ये रूपांतरित करते. दोन प्रकारचे क्लायंट आहेत: एक्झिक्युशन क्लायंट आणि कन्सेन्सस क्लायंट. नोड तयार करण्यासाठी दोन्ही आवश्यक आहेत. व्हॅलिडेटर हा कन्सेन्सस क्लायंटसाठी एक ऐच्छिक ॲड-ऑन आहे जो नोडला प्रूफ-ऑफ-स्टेक कन्सेन्ससमध्ये सहभागी होण्यास सक्षम करतो. याचा अर्थ निवडल्यावर ब्लॉक तयार करणे आणि प्रस्तावित करणे आणि नेटवर्कवर ऐकलेल्या ब्लॉक्सना प्रमाणित करणे. व्हॅलिडेटर चालवण्यासाठी, नोड ऑपरेटरला डिपॉझिट कॉन्ट्रॅक्टमध्ये 32 ETH जमा करणे आवश्यक आहे. + +- [नोड्स आणि क्लायंटवर अधिक](/developers/docs/nodes-and-clients) +- [स्टेकिंगवर अधिक](/staking) + +## प्रूफ-ऑफ-स्टेक ही एक नवीन कल्पना आहे का? {#is-pos-new} + +नाही. BitcoinTalk वरील एका वापरकर्त्याने 2011 मध्ये Bitcoin मध्ये अपग्रेड म्हणून [प्रूफ-ऑफ-स्टेकची मूळ कल्पना प्रस्तावित केली](https://bitcointalk.org/index.php?topic=27787.0). Ethereum मेननेटवर लागू करण्यासाठी तयार होण्यापूर्वी अकरा वर्षे लागली. काही इतर चेन्सनी Ethereum पेक्षा आधी प्रूफ-ऑफ-स्टेक लागू केले, परंतु Ethereumची विशिष्ट यंत्रणा (Gasper म्हणून ओळखली जाणारी) नाही. + +## Ethereum च्या प्रूफ-ऑफ-स्टेकमध्ये काय विशेष आहे? {#why-is-ethereum-pos-special} + +Ethereum ची प्रूफ-ऑफ-स्टेक यंत्रणा तिच्या डिझाइनमध्ये अद्वितीय आहे. ही डिझाइन आणि अंमलात आणलेली पहिली प्रूफ-ऑफ-स्टेक यंत्रणा नव्हती, परंतु ती सर्वात मजबूत आहे. प्रूफ-ऑफ-स्टेक यंत्रणा "Casper" म्हणून ओळखली जाते. Casper हे परिभाषित करते की ब्लॉक प्रस्तावित करण्यासाठी व्हॅलिडेटर्स कसे निवडले जातात, साक्षांकन कसे आणि केव्हा केले जाते, साक्षांकने कशी मोजली जातात, व्हॅलिडेटर्सना दिलेली बक्षिसे आणि दंड, स्लॅशिंग अटी, निष्क्रियता गळतीसारख्या फेलसेफ यंत्रणा आणि "अंतिमता" साठीच्या अटी. अंतिमता ही अशी अट आहे की एखाद्या ब्लॉकला कॅनोनिकल चेनचा कायमस्वरूपी भाग मानण्यासाठी, नेटवर्कवरील एकूण स्टेक केलेल्या ETH पैकी किमान 66% लोकांनी त्यासाठी मतदान केलेले असावे. संशोधकांनी विशेषतः Ethereum साठी Casper विकसित केले, आणि Ethereum ही पहिली आणि एकमेव ब्लॉकचेन आहे जिने ते लागू केले आहे. + +Casper व्यतिरिक्त, Ethereum चे प्रूफ-ऑफ-स्टेक LMD-GHOST नावाचा फोर्क चॉईस अल्गोरिदम वापरते. एकाच स्लॉटसाठी दोन ब्लॉक अस्तित्वात असल्याची स्थिती उद्भवल्यास हे आवश्यक आहे. यामुळे ब्लॉकचेनचे दोन फोर्क तयार होतात. LMD-GHOST सर्वात जास्त साक्षांकनाचे "वजन" असलेले एक निवडते. वजन हे व्हॅलिडेटर्सच्या प्रभावी शिल्लकेनुसार भारित केलेल्या साक्षांकनांची संख्या आहे. LMD-GHOST हे Ethereum साठी अद्वितीय आहे. + +Casper आणि LMD_GHOST यांचे संयोजन Gasper म्हणून ओळखले जाते. + +[Gasper वर अधिक](/developers/docs/consensus-mechanisms/pos/gasper/) + +## स्लॅशिंग म्हणजे काय? {#what-is-slashing} + +स्लॅशिंग ही व्हॅलिडेटरच्या काही स्टेकच्या विनाशास आणि नेटवर्कमधून व्हॅलिडेटरला बाहेर काढण्यास दिलेली संज्ञा आहे. स्लॅशिंगमध्ये गमावलेल्या ETH ची रक्कम स्लॅश केल्या जाणाऱ्या व्हॅलिडेटर्सच्या संख्येनुसार वाढते - याचा अर्थ संगनमत करणाऱ्या व्हॅलिडेटर्सना व्यक्तींपेक्षा अधिक कठोर शिक्षा मिळते. + +[स्लॅशिंगवर अधिक](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## व्हॅलिडेटर्सना 32 ETH ची गरज का आहे? {#why-32-eth} + +व्हॅलिडेटर्सना ETH स्टेक करावे लागते जेणेकरून त्यांनी गैरवर्तन केल्यास त्यांच्याकडे गमावण्यासाठी काहीतरी असेल. त्यांना विशेषतः 32 ETH स्टेक का करावे लागते याचे कारण म्हणजे नोड्सना सामान्य हार्डवेअरवर चालण्यास सक्षम करणे. जर प्रति व्हॅलिडेटर किमान ETH कमी असते, तर व्हॅलिडेटर्सची संख्या आणि त्यामुळे प्रत्येक स्लॉटमध्ये प्रक्रिया कराव्या लागणाऱ्या संदेशांची संख्या वाढली असती, याचा अर्थ नोड चालवण्यासाठी अधिक शक्तिशाली हार्डवेअरची आवश्यकता भासली असती. + +## व्हॅलिडेटर्स कसे निवडले जातात? {#how-are-validators-selected} + +RANDAO नावाच्या अल्गोरिदमचा वापर करून प्रत्येक स्लॉटमध्ये ब्लॉक प्रस्तावित करण्यासाठी एका व्हॅलिडेटरची अर्ध-यादृच्छिकपणे निवड केली जाते, जो ब्लॉक प्रस्तावक कडून एक हॅश प्रत्येक ब्लॉकवर अपडेट होणाऱ्या सीडसह मिसळतो. हे मूल्य एकूण व्हॅलिडेटर सेटमधून विशिष्ट व्हॅलिडेटर निवडण्यासाठी वापरले जाते. व्हॅलिडेटरची निवड दोन इपॉक्स आधी निश्चित केली जाते. + +[व्हॅलिडेटर निवडीवर अधिक](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## स्टेक ग्राइंडिंग म्हणजे काय? {#what-is-stake-grinding} + +स्टेक ग्राइंडिंग हा प्रूफ-ऑफ-स्टेक नेटवर्कवरील हल्ल्याचा एक प्रकार आहे जिथे हल्लेखोर व्हॅलिडेटर निवड अल्गोरिदमला स्वतःच्या व्हॅलिडेटर्सच्या बाजूने झुकवण्याचा प्रयत्न करतो. RANDAO वरील स्टेक ग्राइंडिंग हल्ल्यांसाठी एकूण स्टेक केलेल्या ETH च्या सुमारे अर्ध्या भागाची आवश्यकता असते. + +[स्टेक ग्राइंडिंगवर अधिक](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## सोशल स्लॅशिंग म्हणजे काय? {#what-is-social-slashing} + +सोशल स्लॅशिंग ही हल्ल्याला प्रतिसाद म्हणून ब्लॉकचेनचा फोर्क समन्वयित करण्याची समुदायाची क्षमता आहे. हे समुदायाला अप्रामाणिक चेन अंतिम करणाऱ्या हल्लेखोरापासून सावरण्यास सक्षम करते. सोशल स्लॅशिंग सेन्सॉरशिप हल्ल्यांविरूद्ध देखील वापरले जाऊ शकते. + +- [सोशल स्लॅशिंगवर अधिक](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [विटालिक ब्युटेरिन सोशल स्लॅशिंगवर](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## मला स्लॅश केले जाईल का? {#will-i-get-slashed} + +एक व्हॅलिडेटर म्हणून, जोपर्यंत तुम्ही जाणूनबुजून दुर्भावनापूर्ण वर्तनात गुंतत नाही तोपर्यंत स्लॅश होणे खूप कठीण आहे. स्लॅशिंग फक्त अशा विशिष्ट परिस्थितीत लागू केले जाते जेथे व्हॅलिडेटर्स एकाच स्लॉटसाठी अनेक ब्लॉक प्रस्तावित करतात किंवा त्यांच्या साक्षांकनांनी स्वतःचाच विरोधाभास करतात - हे अपघाताने घडण्याची शक्यता फारच कमी आहे. + +[स्लॅशिंग अटींवर अधिक](https://eth2book.info/altair/part2/incentives/slashing) + +## नथिंग-ॲट-स्टेक समस्या काय आहे? {#what-is-nothing-at-stake-problem} + +नथिंग-ॲट-स्टेक समस्या ही काही प्रूफ-ऑफ-स्टेक यंत्रणांसह एक संकल्पनात्मक समस्या आहे जिथे फक्त बक्षिसे आहेत आणि दंड नाहीत. जर काहीही स्टेकवर नसेल, तर एक व्यावहारिक व्हॅलिडेटर ब्लॉकचेनच्या कोणत्याही, किंवा अगदी एकाधिक, फोर्कला प्रमाणित करण्यास तितकाच आनंदी असतो, कारण यामुळे त्यांची बक्षिसे वाढतात. एक कॅनोनिकल चेन सुनिश्चित करण्यासाठी Ethereum अंतिमता अटी आणि स्लॅशिंगचा वापर करून यावर मात करते. + +[नथिंग-ॲट-स्टेक समस्येवर अधिक](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## फोर्क चॉइस अल्गोरिदम म्हणजे काय? {#what-is-a-fork-choice-algorithm} + +फोर्क चॉइस अल्गोरिदम कोणती चेन कॅनोनिकल आहे हे ठरवणारे नियम लागू करते. इष्टतम परिस्थितीत, फोर्क चॉइस नियमाची आवश्यकता नाही कारण प्रति स्लॉट फक्त एक ब्लॉक प्रस्तावक असतो आणि निवडण्यासाठी एकच ब्लॉक असतो. तथापि, कधीकधी, एकाच स्लॉटसाठी अनेक ब्लॉक किंवा उशीरा येणारी माहिती यामुळे चेनच्या सुरुवातीच्या जवळचे ब्लॉक कसे आयोजित केले जातात यासाठी अनेक पर्याय निर्माण होतात. या प्रकरणांमध्ये, सर्व क्लायंटनी काही नियम समान रीतीने लागू केले पाहिजेत याची खात्री करण्यासाठी की ते सर्व ब्लॉक्सचा योग्य क्रम निवडतील. फोर्क-चॉइस अल्गोरिदम हे नियम एन्कोड करतो. + +Ethereum चा फोर्क-चॉइस अल्गोरिदम LMD-GHOST म्हटला जातो. हे सर्वाधिक साक्षांकनांचे वजन असलेले फोर्क निवडते, म्हणजे ज्यासाठी सर्वाधिक स्टेक केलेल्या ETH ने मतदान केले आहे. + +[LMD-GHOST वर अधिक](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## प्रूफ-ऑफ-स्टेकमध्ये अंतिमता म्हणजे काय? {#what-is-finality} + +प्रूफ-ऑफ-स्टेकमधील अंतिमता ही हमी आहे की दिलेला ब्लॉक कॅनोनिकल चेनचा कायमस्वरूपी भाग आहे आणि तो परत फिरवला जाऊ शकत नाही जोपर्यंत एकमत अयशस्वी होत नाही ज्यामध्ये हल्लेखोर एकूण स्टेक केलेल्या इथरपैकी 33% जाळतो. ही "क्रिप्टो-इकॉनॉमिक" अंतिमता आहे, "प्रोबॅबिलिस्टिक अंतिमता" च्या विरुद्ध जी प्रूफ-ऑफ-वर्क ब्लॉकचेनशी संबंधित आहे. संभाव्य अंतिमतमध्ये, ब्लॉक्ससाठी कोणतीही स्पष्ट अंतिम/अंतिम नसलेली स्थिती नसते - ब्लॉक जसजसा जुना होत जातो तसतसे त्याला चेनमधून काढून टाकण्याची शक्यता कमी होत जाते, आणि वापरकर्ते स्वतः ठरवतात की त्यांना ब्लॉक "सुरक्षित" असल्याची पुरेशी खात्री केव्हा आहे. क्रिप्टो-इकॉनॉमिक अंतिमतासह, चेकपॉईंट ब्लॉक्सच्या जोड्यांसाठी 66% स्टेक केलेल्या इथरद्वारे मतदान करणे आवश्यक आहे. जर ही अट पूर्ण झाली, तर त्या चेकपॉईंट्समधील ब्लॉक स्पष्टपणे "अंतिम" केले जातात. + +[अंतिमतावर अधिक](/developers/docs/consensus-mechanisms/pos/#finality) + +## "वीक सब्जेक्टिव्हिटी" म्हणजे काय? {#what-is-weak-subjectivity} + +वीक सब्जेक्टिव्हिटी हे प्रूफ-ऑफ-स्टेक नेटवर्कचे एक वैशिष्ट्य आहे जिथे ब्लॉकचेनच्या वर्तमान स्थितीची पुष्टी करण्यासाठी सामाजिक माहिती वापरली जाते. नवीन नोड्स किंवा बऱ्याच काळापासून ऑफलाइन राहिल्यानंतर नेटवर्कमध्ये पुन्हा सामील होणाऱ्या नोड्सना अलीकडील स्थिती दिली जाऊ शकते जेणेकरून नोड ताबडतोब पाहू शकेल की ते योग्य चेनवर आहेत की नाही. या स्थितींना "वीक सब्जेक्टिव्हिटी चेकपॉईंट्स" म्हणून ओळखले जाते आणि ते इतर नोड ऑपरेटर्सकडून आउट-ऑफ-बँड, किंवा ब्लॉक एक्सप्लोरर्सकडून, किंवा अनेक सार्वजनिक एंडपॉईंट्सवरून मिळवता येतात. + +[वीक सब्जेक्टिव्हिटीवर अधिक](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## प्रूफ-ऑफ-स्टेक सेन्सॉरशिप-प्रतिरोधक आहे का? {#is-pos-censorship-resistant} + +सेन्सॉरशिप प्रतिकार सध्या सिद्ध करणे कठीण आहे. तथापि, प्रूफ-ऑफ-वर्कच्या विपरीत, प्रूफ-ऑफ-स्टेक सेन्सॉरिंग व्हॅलिडेटर्सना शिक्षा देण्यासाठी स्लॅशिंग समन्वयित करण्याचा पर्याय देते. प्रोटोकॉलमध्ये आगामी बदल आहेत जे ब्लॉक बिल्डर्सना ब्लॉक प्रस्तावक पासून वेगळे करतात आणि बिल्डर्सनी प्रत्येक ब्लॉकमध्ये समाविष्ट कराव्या लागणाऱ्या व्यवहारांच्या सूची लागू करतात. हा प्रस्ताव प्रॉपर-बिल्डर सेपरेशन म्हणून ओळखला जातो आणि व्हॅलिडेटर्सना व्यवहार सेन्सॉर करण्यापासून रोखण्यास मदत करतो. + +[प्रस्तावक-बिल्डर सेपरेशनवर अधिक](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Ethereum च्या प्रूफ-ऑफ-स्टेक प्रणालीवर 51% हल्ला होऊ शकतो का? {#pos-51-attack} + +होय. प्रूफ-ऑफ-वर्कप्रमाणेच प्रूफ-ऑफ-स्टेक 51% हल्ल्यांसाठी असुरक्षित आहे. हल्लेखोराला नेटवर्कच्या हॅश पॉवरच्या 51% ची आवश्यकता असण्याऐवजी, हल्लेखोराला एकूण स्टेक केलेल्या ETH च्या 51% ची आवश्यकता असते. एकूण स्टेकच्या 51% जमा करणारा हल्लेखोर फोर्क-चॉइस अल्गोरिदमवर नियंत्रण मिळवतो. हे हल्लेखोराला विशिष्ट व्यवहार सेन्सॉर करण्यास, शॉर्ट-रेंज रीऑर्ग करण्यास आणि त्यांच्या बाजूने ब्लॉक्सची पुनर्रचना करून MEV काढण्यास सक्षम करते. + +[प्रूफ-ऑफ-स्टेकवरील हल्ल्यांवर अधिक](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## सामाजिक समन्वय म्हणजे काय, आणि त्याची गरज का आहे? {#what-is-social-coordination} + +सामाजिक समन्वय हे Ethereum साठी संरक्षणाची शेवटची ओळ आहे जी अप्रामाणिक ब्लॉक्सना अंतिम करणाऱ्या हल्ल्यातून एक प्रामाणिक चेन पुनर्प्राप्त करण्यास अनुमती देईल. या प्रकरणात, Ethereum समुदायाला "आउट-ऑफ-बँड" समन्वय साधावा लागेल आणि एक प्रामाणिक अल्पसंख्याक फोर्क वापरण्यास सहमती द्यावी लागेल, या प्रक्रियेत हल्लेखोराच्या व्हॅलिडेटर्सना स्लॅश करावे लागेल. यासाठी ॲप्स आणि एक्सचेंजेसना देखील प्रामाणिक फोर्क ओळखणे आवश्यक असेल. + +[सामाजिक समन्वयावर अधिक वाचा](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## प्रूफ-ऑफ-स्टेकमध्ये श्रीमंत अधिक श्रीमंत होतात का? {#do-rich-get-richer} + +एखाद्या व्यक्तीकडे जितके जास्त ETH स्टेक करण्यासाठी असतील, तितके जास्त व्हॅलिडेटर्स ते चालवू शकतात आणि तितके जास्त बक्षिसे ते मिळवू शकतात. बक्षिसे स्टेक केलेल्या ETH च्या रकमेसह रेषीयपणे मोजली जातात आणि प्रत्येकाला समान टक्केवारीचा परतावा मिळतो. प्रूफ-ऑफ-वर्क प्रूफ-ऑफ-स्टेकपेक्षा श्रीमंतांना अधिक समृद्ध करते कारण मोठ्या प्रमाणावर हार्डवेअर खरेदी करणारे श्रीमंत मायनर्स मोठ्या प्रमाणावरील अर्थव्यवस्थेचा फायदा घेतात, याचा अर्थ संपत्ती आणि बक्षीस यांच्यातील संबंध अ-रेखीय आहे. + +## प्रूफ-ऑफ-स्टेक प्रूफ-ऑफ-वर्कपेक्षा अधिक केंद्रीकृत आहे का? {#is-pos-decentralized} + +नाही, प्रूफ-ऑफ-वर्क केंद्रीकरणाकडे झुकते कारण मायनिंगचा खर्च वाढतो आणि व्यक्तींना, नंतर लहान कंपन्यांना आणि इत्यादींना बाहेर काढतो. प्रूफ-ऑफ-स्टेकमधील सध्याची समस्या लिक्विड स्टेकिंग डेरिव्हेटिव्ह्ज (LSDs) चा प्रभाव आहे. हे काही प्रदात्याद्वारे स्टेक केलेल्या ETH चे प्रतिनिधित्व करणारे टोकन आहेत जे कोणीही दुय्यम बाजारांवर स्वॅप करू शकतो, वास्तविक ETH अनस्टेक न करता. LSDs वापरकर्त्यांना 32 ETH पेक्षा कमी रकमेसह स्टेक करण्याची परवानगी देतात, परंतु ते केंद्रीकरणाचा धोका देखील निर्माण करतात जिथे काही मोठ्या संस्था स्टेकच्या मोठ्या भागावर नियंत्रण ठेवू शकतात. म्हणूनच Ethereum साठी [सोलो स्टेकिंग](/staking/solo) हा सर्वोत्तम पर्याय आहे. + +[LSDs मध्ये स्टेक केंद्रीकरणावर अधिक](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## मी फक्त ETH का स्टेक करू शकेन? {#why-can-i-only-stake-eth} + +ETH हे Ethereumचे मूळ चलन आहे. मतांचे वजन आणि सुरक्षिततेसाठी प्रभावी शिल्लक मोजण्यासाठी, सर्व स्टेक एकाच चलनात असणे आवश्यक आहे. ETH स्वतःच स्मार्ट कॉन्ट्रॅक्टऐवजी Ethereum चा एक मूलभूत घटक आहे. इतर चलने समाविष्ट केल्याने स्टेकिंगची गुंतागुंत लक्षणीयरीत्या वाढेल आणि सुरक्षा कमी होईल. + +## Ethereum ही एकमेव प्रूफ-ऑफ-स्टेक ब्लॉकचेन आहे का? {#is-ethereum-the-only-pos-blockchain} + +नाही, अनेक प्रूफ-ऑफ-स्टेक ब्लॉकचेन आहेत. एकही Ethereum सारखी नाही; Ethereum ची प्रूफ-ऑफ-स्टेक यंत्रणा अद्वितीय आहे. + +## द मर्ज म्हणजे काय? {#what-is-the-merge} + +द मर्ज हा तो क्षण होता जेव्हा Ethereum ने आपली प्रूफ-ऑफ-वर्क-आधारित एकमत यंत्रणा बंद केली आणि आपली प्रूफ-ऑफ-स्टेक-आधारित एकमत यंत्रणा चालू केली. द मर्ज 15 सप्टेंबर 2022 रोजी झाला. + +[द मर्जवर अधिक](/roadmap/merge) + +## लाइव्हनेस आणि सेफ्टी म्हणजे काय? {#what-are-liveness-and-safety} + +लाइव्हनेस आणि सेफ्टी या ब्लॉकचेनसाठी दोन मूलभूत सुरक्षा चिंता आहेत. लाइव्हनेस म्हणजे अंतिम होणाऱ्या चेनची उपलब्धता. जर चेन अंतिम होणे थांबवते किंवा वापरकर्ते सहजपणे त्यात प्रवेश करू शकत नाहीत, तर ते लाइव्हनेस अयशस्वी आहेत. प्रवेशाची अत्यंत उच्च किंमत देखील लाइव्हनेस अयशस्वी मानली जाऊ शकते. सेफ्टी म्हणजे चेनवर हल्ला करणे किती कठीण आहे - म्हणजेच, परस्परविरोधी चेकपॉईंट्स अंतिम करणे. + +[Casper पेपरमध्ये अधिक वाचा](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..1ca247ea436 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Gasper प्रूफ-ऑफ-स्टेक यंत्रणेचे स्पष्टीकरण." +lang: mr +--- + +Gasper हे कॅस्पर द फ्रेंडली फायनॅलिटी गॅझेट (Casper-FFG) आणि LMD-GHOST फोर्क निवड अल्गोरिदम यांचे संयोजन आहे. हे घटक एकत्रितपणे प्रूफ-ऑफ-स्टेक Ethereum ला ​​सुरक्षित करणारी एकमत यंत्रणा तयार करतात. कॅस्पर ही एक यंत्रणा आहे जी विशिष्ट ब्लॉक्सना "फायनलाइज्ड" करण्यासाठी अपग्रेड करते जेणेकरून नेटवर्कमधील नवीन प्रवेशकर्ते कॅनॉनिकल चेन सिंक करत असल्याची खात्री बाळगू शकतील. जेव्हा ब्लॉकचेनमध्ये फोर्क तयार होतात तेव्हा नोड्स सहजपणे योग्य फोर्क निवडू शकतील याची खात्री करण्यासाठी फोर्क निवड अल्गोरिदम एकत्रित मतांचा वापर करतो. + +**टीप** Gasper मध्ये समाविष्ट करण्यासाठी Casper-FFG ची मूळ व्याख्या किंचित अद्यतनित केली गेली आहे. या पेजवर आम्ही अद्यतनित आवृत्तीचा विचार करत आहोत. + +## पूर्व आवश्यकता + +ही सामग्री समजून घेण्यासाठी [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) वरील प्रास्ताविक पेज वाचणे आवश्यक आहे. + +## Gasper ची भूमिका {#role-of-gasper} + +Gasper प्रूफ-ऑफ-स्टेक ब्लॉकचेनवर काम करतो जिथे नोड्स सुरक्षा ठेव म्हणून इथर प्रदान करतात, जे ब्लॉक्स प्रस्तावित किंवा प्रमाणित करण्यात आळशी किंवा अप्रामाणिक असल्यास नष्ट केले जाऊ शकते. Gasper ही एक यंत्रणा आहे जी व्हॅलिडेटर्सना कसे पुरस्कृत आणि दंडित केले जाते, कोणते ब्लॉक्स स्वीकारायचे आणि कोणते नाकारायचे आणि ब्लॉकचेनच्या कोणत्या फोर्कवर बिल्ड करायचे हे ठरवते. + +## फायनॅलिटी म्हणजे काय? {#what-is-finality} + +फायनॅलिटी हा विशिष्ट ब्लॉक्सचा एक गुणधर्म आहे, ज्याचा अर्थ असा आहे की जोपर्यंत गंभीर एकमत अयशस्वी होत नाही आणि आक्रमणकर्त्याने एकूण स्टेक केलेल्या इथरपैकी किमान 1/3 नष्ट केला नाही तोपर्यंत ते परत केले जाऊ शकत नाहीत. फायनलाइज्ड ब्लॉक्स ही अशी माहिती मानली जाऊ शकते ज्याबद्दल ब्लॉकचेनला खात्री असते. एका ब्लॉकला फायनलाइज्ड होण्यासाठी दोन-चरणांच्या अपग्रेड प्रक्रियेतून जावे लागते: + +1. एकूण स्टेक केलेल्या इथरपैकी दोन-तृतीयांशने त्या ब्लॉकच्या कॅनॉनिकल चेनमध्ये समावेशाच्या बाजूने मतदान केलेले असावे. ही अट ब्लॉकला "जस्टिफाइड" करण्यासाठी अपग्रेड करते. जस्टिफाइड ब्लॉक्स परत होण्याची शक्यता कमी असते, परंतु काही विशिष्ट परिस्थितीत ते परत केले जाऊ शकतात. +2. जेव्हा एका जस्टिफाइड ब्लॉकवर दुसरा ब्लॉक जस्टिफाइड केला जातो, तेव्हा तो "फायनलाइज्ड" करण्यासाठी अपग्रेड केला जातो. एखादा ब्लॉक फायनलाइज्ड करणे म्हणजे त्या ब्लॉकला कॅनॉनिकल चेनमध्ये समाविष्ट करण्याची वचनबद्धता होय. जोपर्यंत एखादा आक्रमणकर्ता लाखो इथर (अब्जावधी $USD) नष्ट करत नाही तोपर्यंत ते परत केले जाऊ शकत नाही. + +हे ब्लॉक अपग्रेड प्रत्येक स्लॉटमध्ये होत नाहीत. त्याऐवजी, केवळ इपॉक-बाउंडरी ब्लॉक्स जस्टिफाइड आणि फायनलाइज्ड केले जाऊ शकतात. हे ब्लॉक्स "चेकपॉइंट्स" म्हणून ओळखले जातात. अपग्रेड करताना चेकपॉइंट्सच्या जोड्यांचा विचार केला जातो. कमी अलीकडील चेकपॉइंटला फायनलाइज्ड आणि अधिक अलीकडील ब्लॉकला जस्टिफाइड करण्यासाठी दोन सलग चेकपॉइंट्समध्ये एक "सुपरमेजोरिटी लिंक" अस्तित्वात असणे आवश्यक आहे (म्हणजे, एकूण स्टेक केलेल्या इथरपैकी दोन-तृतीयांशने मतदान केले आहे की चेकपॉइंट B हा चेकपॉइंट A चा योग्य वंशज आहे). + +कारण फायनॅलिटीसाठी एखादा ब्लॉक कॅनॉनिकल असल्याची दोन-तृतीयांश सहमती आवश्यक असते, त्यामुळे आक्रमणकर्ता खालील गोष्टींशिवाय पर्यायी फायनलाइज्ड चेन तयार करू शकत नाही: + +1. एकूण स्टेक केलेल्या इथरपैकी दोन-तृतीयांशची मालकी असणे किंवा हाताळणी करणे. +2. एकूण स्टेक केलेल्या इथरपैकी किमान एक-तृतीयांश नष्ट करणे. + +पहिली अट उद्भवते कारण एखादी चेन फायनलाइज्ड करण्यासाठी दोन-तृतीयांश स्टेक केलेला इथर आवश्यक असतो. दुसरी अट उद्भवते कारण जर एकूण स्टेकपैकी दोन-तृतीयांशने दोन्ही फोर्कच्या बाजूने मतदान केले असेल, तर एक-तृतीयांशने दोन्हीवर मतदान केले असले पाहिजे. दुहेरी-मतदान ही एक स्लॅशिंग अट आहे ज्यासाठी कमाल शिक्षा दिली जाईल, आणि एकूण स्टेकपैकी एक-तृतीयांश नष्ट केला जाईल. मे २०२२ पर्यंत, यासाठी आक्रमणकर्त्याला सुमारे $10 अब्ज किमतीचे इथर जाळावे लागतील. Gasper मध्ये ब्लॉक्सना जस्टिफाइड आणि फायनलाइज्ड करणारा अल्गोरिदम हा [कॅस्पर द फ्रेंडली फायनॅलिटी गॅझेट (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) चे थोडे सुधारित स्वरूप आहे. + +### प्रोत्साहन आणि स्लॅशिंग {#incentives-and-slashing} + +व्हॅलिडेटर्सना प्रामाणिकपणे ब्लॉक्स प्रस्तावित आणि प्रमाणित करण्यासाठी पुरस्कृत केले जाते. इथर पुरस्कृत केले जाते आणि त्यांच्या स्टेकमध्ये जोडले जाते. दुसरीकडे, जे व्हॅलिडेटर्स अनुपस्थित असतात आणि बोलावल्यावर कार्य करण्यास अयशस्वी ठरतात, त्यांना हे पुरस्कार मिळत नाहीत आणि कधीकधी त्यांच्या विद्यमान स्टेकचा एक छोटा भाग गमावतात. तथापि, ऑफलाइन असण्याचे दंड लहान आहेत आणि, बहुतेक प्रकरणांमध्ये, ते पुरस्कार गमावण्याच्या संधीच्या खर्चाएवढे असतात. तथापि, काही व्हॅलिडेटर क्रिया अपघाताने करणे खूप कठीण आहे आणि काही दुर्भावनापूर्ण हेतू दर्शवतात, जसे की एकाच स्लॉटसाठी अनेक ब्लॉक्स प्रस्तावित करणे, एकाच स्लॉटसाठी अनेक ब्लॉक्सची साक्ष देणे किंवा मागील चेकपॉइंट मतांशी विरोधाभास करणे. हे "स्लॅश करण्यायोग्य" वर्तन आहेत ज्यांना अधिक कठोर शिक्षा दिली जाते—स्लॅशिंगमुळे व्हॅलिडेटरच्या स्टेकचा काही भाग नष्ट होतो आणि व्हॅलिडेटरला व्हॅलिडेटर्सच्या नेटवर्कमधून काढून टाकले जाते. या प्रक्रियेला ३६ दिवस लागतात. पहिल्या दिवशी, १ ETH पर्यंतचा प्रारंभिक दंड आकारला जातो. नंतर एक्झिट कालावधीत स्लॅश झालेल्या व्हॅलिडेटरचा इथर हळूहळू कमी होत जातो, परंतु १८ व्या दिवशी, त्यांना "सहसंबंध दंड" मिळतो, जो एकाच वेळी अधिक व्हॅलिडेटर्सना स्लॅश केले जाते तेव्हा मोठा असतो. कमाल दंड म्हणजे संपूर्ण स्टेक. हे पुरस्कार आणि दंड प्रामाणिक व्हॅलिडेटर्सना प्रोत्साहन देण्यासाठी आणि नेटवर्कवरील हल्ल्यांना परावृत्त करण्यासाठी डिझाइन केलेले आहेत. + +### निष्क्रियता गळती {#inactivity-leak} + +सुरक्षेसोबतच, Gasper "संभाव्य लाइव्हनेस" देखील प्रदान करतो. ही अशी अट आहे की जोपर्यंत एकूण स्टेक केलेल्या इथरपैकी दोन-तृतीयांश प्रामाणिकपणे मतदान करत आहे आणि प्रोटोकॉलचे पालन करत आहे, तोपर्यंत इतर कोणत्याही हालचालीची (जसे की हल्ले, लेटन्सी समस्या किंवा स्लॅशिंग) पर्वा न करता चेन फायनलाइज्ड होऊ शकेल. दुसऱ्या शब्दांत, चेनला फायनलाइज्ड होण्यापासून रोखण्यासाठी एकूण स्टेक केलेल्या इथरपैकी एक-तृतीयांशाशी कोणत्यातरी प्रकारे तडजोड केली पाहिजे. Gasper मध्ये, लाइव्हनेस अयशस्वी होण्याच्या विरोधात संरक्षणाची एक अतिरिक्त रेषा आहे, जी "निष्क्रियता गळती" म्हणून ओळखली जाते. जेव्हा चेन चारपेक्षा जास्त इपॉक्ससाठी फायनलाइज्ड होण्यास अयशस्वी ठरते तेव्हा ही यंत्रणा सक्रिय होते. जे व्हॅलिडेटर्स बहुसंख्य चेनला सक्रियपणे साक्ष देत नाहीत, त्यांचा स्टेक हळूहळू कमी होत जातो जोपर्यंत बहुसंख्यांना एकूण स्टेकपैकी दोन-तृतीयांश परत मिळत नाही, ज्यामुळे हे सुनिश्चित होते की लाइव्हनेस अपयश केवळ तात्पुरते आहेत. + +### फोर्क निवड {#fork-choice} + +Casper-FFG च्या मूळ व्याख्येत एक फोर्क निवड अल्गोरिदम समाविष्ट होता ज्याने हा नियम लागू केला: `सर्वात जास्त उंची असलेल्या जस्टिफाइड चेकपॉइंटचा समावेश असलेल्या चेनचे अनुसरण करा` जिथे उंचीची व्याख्या जेनेसिस ब्लॉकपासूनचे सर्वात मोठे अंतर अशी केली आहे. Gasper मध्ये, LMD-GHOST नावाच्या अधिक अत्याधुनिक अल्गोरिदमच्या बाजूने मूळ फोर्क निवड नियम नापसंत केला आहे. हे लक्षात घेणे महत्त्वाचे आहे की सामान्य परिस्थितीत, फोर्क निवड नियमाची आवश्यकता नसते - प्रत्येक स्लॉटसाठी एकच ब्लॉक प्रस्तावक असतो, आणि प्रामाणिक व्हॅलिडेटर्स त्याला साक्ष देतात. केवळ मोठ्या नेटवर्क असिंक्रोनिसिटीच्या प्रकरणांमध्ये किंवा जेव्हा एखादा अप्रामाणिक ब्लॉक प्रस्तावक संदिग्ध विधान करतो तेव्हाच फोर्क निवड अल्गोरिदम आवश्यक असतो. तथापि, जेव्हा अशी प्रकरणे उद्भवतात, तेव्हा फोर्क निवड अल्गोरिदम एक महत्त्वपूर्ण संरक्षण आहे जे योग्य चेन सुरक्षित करते. + +LMD-GHOST चा अर्थ आहे "लेटेस्ट मेसेज-ड्रिव्हन ग्रीडी हेवीएस्ट ऑब्झर्व्हड सब-ट्री". एखाद्या अल्गोरिदमची व्याख्या करण्याचा हा एक तांत्रिक शब्दबंबाळ मार्ग आहे, जो साक्ष्यांच्या सर्वात मोठ्या एकत्रित वजनासह असलेला फोर्क कॅनॉनिकल म्हणून निवडतो (ग्रीडी हेवीएस्ट सबट्री) आणि जर एखाद्या व्हॅलिडेटरकडून अनेक संदेश प्राप्त झाले, तर केवळ नवीनतम संदेश विचारात घेतला जातो (लेटेस्ट-मेसेज ड्रिव्हन). सर्वात वजनदार ब्लॉकला आपल्या कॅनॉनिकल चेनमध्ये जोडण्यापूर्वी, प्रत्येक व्हॅलिडेटर या नियमाचा वापर करून प्रत्येक ब्लॉकचे मूल्यांकन करतो. + +## अधिक वाचन {#further-reading} + +- [Gasper: GHOST आणि Casper एकत्र करणे](https://arxiv.org/pdf/2003.03052.pdf) +- [कॅस्पर द फ्रेंडली फायनॅलिटी गॅझेट](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..7efa82a6630 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "प्रूफ-ऑफ-स्टेक (PoS)" +description: "प्रूफ-ऑफ-स्टेक सहमती प्रोटोकॉल आणि Ethereum मधील त्याच्या भूमिकेचे स्पष्टीकरण." +lang: mr +--- + +प्रूफ-ऑफ-स्टेक (PoS) हे Ethereum च्या [सहमती यंत्रणेचा](/developers/docs/consensus-mechanisms/) आधार आहे. Ethereum ने 2022 मध्ये त्याच्या प्रूफ-ऑफ-स्टेक यंत्रणेवर स्विच केले कारण ते पूर्वीच्या [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow) आर्किटेक्चरच्या तुलनेत अधिक सुरक्षित, कमी ऊर्जा-केंद्रित आणि नवीन स्केलिंग सोल्यूशन्स लागू करण्यासाठी अधिक चांगले आहे. + +## पूर्वतयारी {#prerequisites} + +हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [सहमती यंत्रणेवर](/developers/docs/consensus-mechanisms/) वाचा. + +## प्रूफ-ऑफ-स्टेक (PoS) म्हणजे काय? {#what-is-pos} + +प्रूफ-ऑफ-स्टेक हा एक मार्ग आहे ज्याद्वारे व्हॅलिडेटर्सनी नेटवर्कमध्ये काहीतरी मौल्यवान ठेवले आहे हे सिद्ध करता येते, जे ते अप्रामाणिकपणे वागल्यास नष्ट केले जाऊ शकते. Ethereum च्या प्रूफ-ऑफ-स्टेकमध्ये, व्हॅलिडेटर्स स्पष्टपणे ETH च्या स्वरूपात भांडवल Ethereum वरील स्मार्ट कॉन्ट्रॅक्टमध्ये स्टेक करतात. त्यानंतर व्हॅलिडेटर नेटवर्कवर प्रसारित झालेले नवीन ब्लॉक्स वैध आहेत की नाही हे तपासण्यासाठी आणि कधीकधी स्वतः नवीन ब्लॉक्स तयार करून प्रसारित करण्यासाठी जबाबदार असतो. जर त्यांनी नेटवर्कची फसवणूक करण्याचा प्रयत्न केला (उदाहरणार्थ, जेव्हा त्यांनी एक ब्लॉक पाठवायला हवा तेव्हा अनेक ब्लॉक्स प्रस्तावित करून किंवा परस्परविरोधी अटेस्टेशन्स पाठवून), तर त्यांचे काही किंवा सर्व स्टेक केलेले ETH नष्ट केले जाऊ शकतात. + +## व्हॅलिडेटर्स {#validators} + +व्हॅलिडेटर म्हणून सहभागी होण्यासाठी, वापरकर्त्याने डिपॉझिट कॉन्ट्रॅक्टमध्ये 32 ETH जमा करणे आवश्यक आहे आणि सॉफ्टवेअरचे तीन वेगळे भाग चालवणे आवश्यक आहे: एक एक्झिक्युशन क्लायंट, एक कन्सेन्सस क्लायंट आणि एक व्हॅलिडेटर क्लायंट. त्यांचे ETH जमा केल्यावर, वापरकर्ता एका ॲक्टिव्हेशन रांगेत सामील होतो जी नेटवर्कमध्ये सामील होणाऱ्या नवीन व्हॅलिडेटर्सचा दर मर्यादित करते. एकदा सक्रिय झाल्यावर, व्हॅलिडेटर्सना Ethereum नेटवर्कवरील पीअर्सकडून नवीन ब्लॉक्स मिळतात. Ethereum च्या स्टेटमध्ये प्रस्तावित बदल वैध आहेत की नाही हे तपासण्यासाठी ब्लॉकमध्ये वितरित केलेले व्यवहार पुन्हा कार्यान्वित केले जातात आणि ब्लॉक स्वाक्षरी तपासली जाते. त्यानंतर व्हॅलिडेटर त्या ब्लॉकच्या बाजूने एक मत (ज्याला अटेस्टेशन म्हणतात) नेटवर्कवर पाठवतो. + +प्रूफ-ऑफ-वर्क अंतर्गत, ब्लॉक्सची वेळ मायनिंग डिफिकल्टीद्वारे निश्चित केली जाते, तर प्रूफ-ऑफ-स्टेकमध्ये, टेम्पो निश्चित असतो. प्रूफ-ऑफ-स्टेक Ethereum मधील वेळ स्लॉट्स (12 सेकंद) आणि इपॉक्स (32 स्लॉट्स) मध्ये विभागलेली आहे. प्रत्येक स्लॉटमध्ये एक व्हॅलिडेटर यादृच्छिकपणे ब्लॉक प्रस्तावक म्हणून निवडला जातो. हा व्हॅलिडेटर एक नवीन ब्लॉक तयार करण्यासाठी आणि तो नेटवर्कवरील इतर नोड्सना पाठवण्यासाठी जबाबदार असतो. तसेच प्रत्येक स्लॉटमध्ये, व्हॅलिडेटर्सची एक समिती यादृच्छिकपणे निवडली जाते, ज्यांच्या मतांचा वापर प्रस्तावित केलेल्या ब्लॉकची वैधता निश्चित करण्यासाठी केला जातो. नेटवर्क लोड व्यवस्थापनीय ठेवण्यासाठी व्हॅलिडेटर संच समित्यांमध्ये विभागणे महत्त्वाचे आहे. समित्या व्हॅलिडेटर संच अशा प्रकारे विभागतात की प्रत्येक सक्रिय व्हॅलिडेटर प्रत्येक इपॉकमध्ये अटेस्ट करतो, परंतु प्रत्येक स्लॉटमध्ये नाही. + +## Ethereum PoS मध्ये व्यवहार कसा कार्यान्वित होतो {#transaction-execution-ethereum-pos} + +खालील माहिती Ethereum प्रूफ-ऑफ-स्टेकमध्ये व्यवहार कसा कार्यान्वित होतो याचे सुरुवातीपासून शेवटपर्यंतचे स्पष्टीकरण देते. + +1. एक वापरकर्ता त्यांच्या प्रायव्हेट की सह [व्यवहार](/developers/docs/transactions/) तयार करतो आणि स्वाक्षरी करतो. हे सहसा वॉलेट किंवा [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) इत्यादी लायब्ररीद्वारे हाताळले जाते, परंतु प्रत्यक्षात वापरकर्ता Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) वापरून नोडला विनंती करत असतो. वापरकर्ता गॅसची रक्कम परिभाषित करतो जी ते व्हॅलिडेटरला टिप म्हणून देण्यास तयार असतात जेणेकरून त्यांना व्यवहाराला ब्लॉकमध्ये समाविष्ट करण्यास प्रोत्साहित केले जाईल. [टिप्स](/developers/docs/gas/#priority-fee) व्हॅलिडेटरला दिले जातात, तर [बेस फी](/developers/docs/gas/#base-fee) बर्न केली जाते. +2. व्यवहार Ethereum [एक्झिक्युशन क्लायंट](/developers/docs/nodes-and-clients/#execution-client) कडे सबमिट केला जातो जो त्याची वैधता सत्यापित करतो. याचा अर्थ प्रेषकाकडे व्यवहार पूर्ण करण्यासाठी पुरेसे ETH आहे आणि त्यांनी योग्य की सह त्यावर स्वाक्षरी केली आहे याची खात्री करणे. +3. जर व्यवहार वैध असेल, तर एक्झिक्युशन क्लायंट तो त्याच्या स्थानिक मेमपूलमध्ये (प्रलंबित व्यवहारांची यादी) जोडतो आणि एक्झिक्युशन लेयर गॉसिप नेटवर्कवर इतर नोड्सना देखील प्रसारित करतो. जेव्हा इतर नोड्सना व्यवहाराबद्दल कळते, तेव्हा ते देखील त्याला त्यांच्या स्थानिक मेमपूलमध्ये जोडतात. प्रगत वापरकर्ते कदाचित त्यांचा व्यवहार प्रसारित करण्यापासून परावृत्त होतील आणि त्याऐवजी तो [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview) सारख्या विशेष ब्लॉक बिल्डर्सकडे पाठवतील. हे त्यांना जास्तीत जास्त नफ्यासाठी ([MEV](/developers/docs/mev/#mev-extraction)) आगामी ब्लॉक्समधील व्यवहार आयोजित करण्याची परवानगी देते. +4. नेटवर्कवरील व्हॅलिडेटर नोड्सपैकी एक सध्याच्या स्लॉटसाठी ब्लॉक प्रस्तावक आहे, जो पूर्वी RANDAO वापरून छद्म-यादृच्छिकपणे निवडला गेला होता. हा नोड Ethereum ब्लॉकचेनमध्ये जोडला जाणारा पुढील ब्लॉक तयार करण्यासाठी आणि प्रसारित करण्यासाठी आणि ग्लोबल स्टेट अद्यतनित करण्यासाठी जबाबदार आहे. नोड तीन भागांनी बनलेला आहे: एक एक्झिक्युशन क्लायंट, एक कन्सेन्सस क्लायंट आणि एक व्हॅलिडेटर क्लायंट. एक्झिक्युशन क्लायंट स्थानिक मेमपूलमधील व्यवहार "एक्झिक्युशन पेलोड" मध्ये बंडल करतो आणि स्टेट बदल निर्माण करण्यासाठी त्यांना स्थानिकरित्या कार्यान्वित करतो. ही माहिती कन्सेन्सस क्लायंटला दिली जाते जिथे एक्झिक्युशन पेलोड "बीकन ब्लॉक" चा भाग म्हणून गुंडाळला जातो, ज्यात रिवॉर्ड्स, पेनल्टी, स्लॅशिंग, अटेस्टेशन्स इत्यादींबद्दलची माहिती देखील असते, जे नेटवर्कला चेनच्या हेडवरील ब्लॉक्सच्या क्रमावर सहमत होण्यास सक्षम करते. एक्झिक्युशन आणि कन्सेन्सस क्लायंटमधील संवाद [Connecting the Consensus and Execution Clients](/developers/docs/networking-layer/#connecting-clients) मध्ये अधिक तपशीलवार वर्णन केले आहे. +5. इतर नोड्सना कन्सेन्सस लेयर गॉसिप नेटवर्कवर नवीन बीकन ब्लॉक मिळतो. ते तो त्यांच्या एक्झिक्युशन क्लायंटकडे पाठवतात जिथे प्रस्तावित स्टेट बदल वैध आहे याची खात्री करण्यासाठी व्यवहार स्थानिकरित्या पुन्हा कार्यान्वित केले जातात. त्यानंतर व्हॅलिडेटर क्लायंट अटेस्ट करतो की ब्लॉक वैध आहे आणि त्यांच्या चेनच्या दृश्यात तो तार्किक पुढील ब्लॉक आहे (म्हणजे तो [फोर्क चॉइस नियमांनुसार](/developers/docs/consensus-mechanisms/pos/#fork-choice) परिभाषित केल्यानुसार अटेस्टेशन्सच्या सर्वाधिक वजनासह चेनवर तयार होतो). ब्लॉक प्रत्येक नोडमधील स्थानिक डेटाबेसमध्ये जोडला जातो जो त्याला अटेस्ट करतो. +6. जर व्यवहार दोन चेकपॉइंट्समधील "सुपरमजॉरिटी लिंक" सह चेनचा भाग बनला असेल तर तो "फायनलाइज्ड" मानला जाऊ शकतो. चेकपॉइंट्स प्रत्येक इपॉकच्या सुरुवातीला येतात आणि ते या वस्तुस्थितीचा हिशोब ठेवण्यासाठी अस्तित्वात आहेत की प्रत्येक स्लॉटमध्ये केवळ सक्रिय व्हॅलिडेटर्सचा उपसंच अटेस्ट करतो, परंतु सर्व सक्रिय व्हॅलिडेटर्स प्रत्येक इपॉकमध्ये अटेस्ट करतात. म्हणून, केवळ इपॉक्सच्या दरम्यान 'सुपरमजॉरिटी लिंक' प्रदर्शित केली जाऊ शकते (येथे नेटवर्कवरील एकूण स्टेक केलेल्या ETH पैकी 66% दोन चेकपॉइंट्सवर सहमत असतात). + +फायनॅलिटीबद्दल अधिक तपशील खाली आढळू शकतो. + +## अंतिमता {#finality} + +वितरित नेटवर्कमध्ये व्यवहाराला "फायनॅलिटी" असते जेव्हा तो अशा ब्लॉकचा भाग असतो जो मोठ्या प्रमाणात ETH बर्न केल्याशिवाय बदलू शकत नाही. प्रूफ-ऑफ-स्टेक Ethereum वर, हे "चेकपॉइंट" ब्लॉक्स वापरून व्यवस्थापित केले जाते. प्रत्येक इपॉकमधील पहिला ब्लॉक एक चेकपॉइंट असतो. व्हॅलिडेटर्स चेकपॉइंट्सच्या जोड्यांसाठी मतदान करतात ज्यांना ते वैध मानतात. जर चेकपॉइंट्सच्या जोडीने एकूण स्टेक केलेल्या ETH च्या किमान दोन-तृतीयांश मतांचे प्रतिनिधित्व करणारी मते आकर्षित केली, तर चेकपॉइंट्स अपग्रेड केले जातात. दोघांपैकी अलीकडील (लक्ष्य) "न्यायोचित" बनतो. दोघांपैकी पूर्वीचा आधीच न्यायोचित आहे कारण तो मागील इपॉकमध्ये "लक्ष्य" होता. आता तो "फायनलाइज्ड" मध्ये अपग्रेड केला आहे. चेकपॉइंट्स अपग्रेड करण्याची ही प्रक्रिया **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)** द्वारे हाताळली जाते. Casper-FFG हे सहमतीसाठी एक ब्लॉक फायनॅलिटी टूल आहे. एकदा ब्लॉक फायनलाइज झाल्यावर, स्टेकर्सच्या बहुसंख्य स्लॅशिंगशिवाय तो परत केला किंवा बदलला जाऊ शकत नाही, ज्यामुळे तो आर्थिकदृष्ट्या अव्यवहार्य बनतो. + +फायनलाइज्ड ब्लॉक परत करण्यासाठी, आक्रमणकर्त्याला एकूण स्टेक केलेल्या ETH पुरवठ्यापैकी किमान एक-तृतीयांश गमावण्याची तयारी ठेवावी लागेल. याचे नेमके कारण या [Ethereum Foundation ब्लॉग पोस्टमध्ये](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) स्पष्ट केले आहे. फायनॅलिटीसाठी दोन-तृतीयांश बहुमताची आवश्यकता असल्याने, आक्रमणकर्ता एकूण स्टेकच्या एक-तृतीयांश मताने मतदान करून नेटवर्कला फायनॅलिटीपर्यंत पोहोचण्यापासून रोखू शकतो. याविरुद्ध बचाव करण्यासाठी एक यंत्रणा आहे: [निष्क्रियता गळती (inactivity leak)](https://eth2book.info/bellatrix/part2/incentives/inactivity). जेव्हा चेन चारपेक्षा जास्त इपॉक्ससाठी फायनलाइज करण्यात अयशस्वी होते तेव्हा हे सक्रिय होते. निष्क्रियता गळती बहुमताच्या विरोधात मतदान करणाऱ्या व्हॅलिडेटर्सकडून स्टेक केलेले ETH काढून टाकते, ज्यामुळे बहुमताला दोन-तृतीयांश बहुमत पुन्हा मिळवता येते आणि चेन फायनलाइज करता येते. + +## क्रिप्टो-इकॉनॉमिक सुरक्षा {#crypto-economic-security} + +व्हॅलिडेटर चालवणे ही एक वचनबद्धता आहे. ब्लॉक व्हॅलिडेशन आणि प्रस्तावामध्ये सहभागी होण्यासाठी व्हॅलिडेटरने पुरेसे हार्डवेअर आणि कनेक्टिव्हिटी राखणे अपेक्षित आहे. बदल्यात, व्हॅलिडेटरला ETH मध्ये पैसे दिले जातात (त्यांची स्टेक केलेली शिल्लक वाढते). दुसरीकडे, व्हॅलिडेटर म्हणून सहभागी होण्याने वापरकर्त्यांना वैयक्तिक लाभासाठी किंवा तोडफोडीसाठी नेटवर्कवर हल्ला करण्याचे नवीन मार्ग देखील मिळतात. हे टाळण्यासाठी, व्हॅलिडेटर्सना बोलावल्यावर सहभागी होण्यात अयशस्वी झाल्यास ETH रिवॉर्ड्स मिळत नाहीत, आणि त्यांनी अप्रामाणिकपणे वागल्यास त्यांचा विद्यमान स्टेक नष्ट केला जाऊ शकतो. दोन प्राथमिक वर्तनांना अप्रामाणिक मानले जाऊ शकते: एकाच स्लॉटमध्ये अनेक ब्लॉक्स प्रस्तावित करणे (संदिग्धता) आणि परस्परविरोधी अटेस्टेशन्स सबमिट करणे. + +स्लॅश केलेल्या ETH ची रक्कम त्याच वेळी किती व्हॅलिडेटर्सना स्लॅश केले जात आहे यावर अवलंबून असते. याला ["सहसंबंध दंड" (correlation penalty)](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) म्हणून ओळखले जाते, आणि तो किरकोळ असू शकतो (स्वतः स्लॅश झालेल्या एका व्हॅलिडेटरसाठी ~1% स्टेक) किंवा व्हॅलिडेटरच्या 100% स्टेक नष्ट होण्यास कारणीभूत ठरू शकतो (मोठ्या प्रमाणावर स्लॅशिंगची घटना). हे एका जबरदस्तीने बाहेर पडण्याच्या कालावधीच्या मध्यभागी लादले जाते, जे पहिल्या दिवशी तात्काळ दंडाने (1 ETH पर्यंत) सुरू होते, 18 व्या दिवशी सहसंबंध दंड, आणि शेवटी, 36 व्या दिवशी नेटवर्कमधून बाहेर काढले जाते. त्यांना दररोज किरकोळ अटेस्टेशन दंड मिळतो कारण ते नेटवर्कवर उपस्थित असतात परंतु मते सबमिट करत नाहीत. या सर्वांचा अर्थ असा आहे की समन्वित हल्ला आक्रमणकर्त्यासाठी खूप महाग असेल. + +## फोर्क निवड {#fork-choice} + +जेव्हा नेटवर्क उत्कृष्टपणे आणि प्रामाणिकपणे कार्य करते, तेव्हा चेनच्या हेडवर नेहमी फक्त एक नवीन ब्लॉक असतो, आणि सर्व व्हॅलिडेटर्स त्याला अटेस्ट करतात. तथापि, नेटवर्क लेटन्सीमुळे किंवा ब्लॉक प्रस्तावकाने संदिग्धता केल्यामुळे व्हॅलिडेटर्सना चेनच्या हेडबद्दल वेगवेगळी मते असणे शक्य आहे. म्हणून, कन्सेन्सस क्लायंट्सना कोणाला प्राधान्य द्यायचे हे ठरवण्यासाठी एका अल्गोरिदमची आवश्यकता असते. प्रूफ-ऑफ-स्टेक Ethereum मध्ये वापरल्या जाणाऱ्या अल्गोरिदमला [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) म्हणतात, आणि तो त्याच्या इतिहासात सर्वाधिक अटेस्टेशन्सचे वजन असलेल्या फोर्कला ओळखून कार्य करतो. + +## प्रूफ-ऑफ-स्टेक आणि सुरक्षा {#pos-and-security} + +[51% हल्ल्याचा](https://www.investopedia.com/terms/1/51-attack.asp) धोका प्रूफ-ऑफ-वर्क प्रमाणेच प्रूफ-ऑफ-स्टेकमध्येही अस्तित्वात आहे, परंतु तो आक्रमणकर्त्यांसाठी अधिक धोकादायक आहे. आक्रमणकर्त्याला 51% स्टेक केलेल्या ETH ची आवश्यकता असेल. त्यानंतर ते त्यांच्या स्वतःच्या अटेस्टेशन्सचा वापर करून त्यांचा पसंतीचा फोर्क सर्वाधिक जमा झालेल्या अटेस्टेशन्सचा आहे याची खात्री करू शकतील. जमा झालेल्या अटेस्टेशन्सचे 'वजन' हेच कन्सेन्सस क्लायंट योग्य चेन निश्चित करण्यासाठी वापरतात, त्यामुळे हा आक्रमणकर्ता त्यांचा फोर्क कॅनॉनिकल बनवू शकेल. तथापि, प्रूफ-ऑफ-वर्कच्या तुलनेत प्रूफ-ऑफ-स्टेकची एक ताकद ही आहे की समुदायाकडे प्रति-हल्ला करण्यासाठी लवचिकता आहे. उदाहरणार्थ, प्रामाणिक व्हॅलिडेटर्स अल्पसंख्याक चेनवर बांधकाम सुरू ठेवण्याचा आणि आक्रमणकर्त्याच्या फोर्ककडे दुर्लक्ष करण्याचा निर्णय घेऊ शकतात, तसेच ॲप्स, एक्सचेंजेस आणि पूल्सना असे करण्यास प्रोत्साहित करू शकतात. ते आक्रमणकर्त्याला नेटवर्कमधून जबरदस्तीने काढून टाकण्याचा आणि त्यांचे स्टेक केलेले ETH नष्ट करण्याचा निर्णय घेऊ शकतात. हे 51% हल्ल्याविरुद्ध मजबूत आर्थिक संरक्षण आहेत. + +51% हल्ल्यांव्यतिरिक्त, दुर्भावनापूर्ण घटक इतर प्रकारच्या द्वेषपूर्ण क्रियाकलापांचा प्रयत्न करू शकतात, जसे की: + +- लांब पल्ल्याचे हल्ले (जरी फायनॅलिटी गॅझेट हा हल्ला वेक्टर निष्प्रभ करते) +- लहान पल्ल्याचे 'रीऑर्ग्स' (जरी प्रस्तावक बूस्टिंग आणि अटेस्टेशन डेडलाइन हे कमी करतात) +- बाउन्सिंग आणि बॅलन्सिंग हल्ले (हे देखील प्रस्तावक बूस्टिंगद्वारे कमी केले जातात, आणि हे हल्ले केवळ आदर्श नेटवर्क परिस्थितीतच प्रदर्शित केले गेले आहेत) +- ॲव्हालांच हल्ले (फक्त नवीनतम संदेशाचा विचार करण्याच्या फोर्क निवड अल्गोरिदमच्या नियमाद्वारे निष्प्रभ) + +एकंदरीत, प्रूफ-ऑफ-स्टेक, जसे की ते Ethereum वर लागू केले आहे, प्रूफ-ऑफ-वर्कपेक्षा अधिक आर्थिकदृष्ट्या सुरक्षित असल्याचे सिद्ध झाले आहे. + +## फायदे आणि तोटे {#pros-and-cons} + +| फायदे | बाधक | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| स्टेकिंगमुळे व्यक्तींना नेटवर्क सुरक्षित करण्यात सहभागी होणे सोपे होते, ज्यामुळे विकेंद्रीकरणाला चालना मिळते. व्हॅलिडेटर नोड सामान्य लॅपटॉपवर चालवला जाऊ शकतो. स्टेकिंग पूल्स वापरकर्त्यांना 32 ETH नसतानाही स्टेक करण्याची परवानगी देतात. | प्रूफ-ऑफ-स्टेक प्रूफ-ऑफ-वर्कच्या तुलनेत नवीन आणि कमी युद्ध-परीक्षित आहे | +| स्टेकिंग अधिक विकेंद्रित आहे. स्केलची अर्थव्यवस्था PoW मायनिंगसाठी लागू होते तशीच लागू होत नाही. | प्रूफ-ऑफ-स्टेक प्रूफ-ऑफ-वर्कपेक्षा लागू करण्यासाठी अधिक जटिल आहे | +| प्रूफ-ऑफ-स्टेक प्रूफ-ऑफ-वर्कपेक्षा अधिक क्रिप्टो-इकॉनॉमिक सुरक्षा प्रदान करते | वापरकर्त्यांना Ethereum च्या प्रूफ-ऑफ-स्टेकमध्ये सहभागी होण्यासाठी सॉफ्टवेअरचे तीन भाग चालवणे आवश्यक आहे. | +| नेटवर्क सहभागींना प्रोत्साहन देण्यासाठी नवीन ETH चे कमी उत्सर्जन आवश्यक आहे | | + +### प्रूफ-ऑफ-वर्कशी तुलना {#comparison-to-proof-of-work} + +Ethereum ने मूळतः प्रूफ-ऑफ-वर्क वापरले परंतु सप्टेंबर 2022 मध्ये प्रूफ-ऑफ-स्टेकमध्ये स्विच केले. PoS चे PoW पेक्षा अनेक फायदे आहेत, जसे की: + +- उत्तम ऊर्जा कार्यक्षमता – प्रूफ-ऑफ-वर्क गणनेवर जास्त ऊर्जा वापरण्याची गरज नाही +- प्रवेशासाठी कमी अडथळे, कमी हार्डवेअर आवश्यकता – नवीन ब्लॉक्स तयार करण्याची संधी मिळवण्यासाठी उच्चभ्रू हार्डवेअरची गरज नाही +- केंद्रीकरणाचा धोका कमी – प्रूफ-ऑफ-स्टेकमुळे नेटवर्क सुरक्षित करणारे अधिक नोड्स तयार झाले पाहिजेत +- कमी ऊर्जेच्या आवश्यकतेमुळे सहभागाला प्रोत्साहन देण्यासाठी कमी ETH उत्सर्जन आवश्यक आहे +- गैरवर्तनासाठी आर्थिक दंडामुळे प्रूफ-ऑफ-वर्कच्या तुलनेत आक्रमणकर्त्यासाठी 51% शैलीचे हल्ले अधिक महाग होतात +- जर 51% हल्ला क्रिप्टो-इकॉनॉमिक संरक्षणावर मात करत असेल तर समुदाय एका प्रामाणिक चेनच्या सामाजिक पुनर्प्राप्तीचा अवलंब करू शकतो. + +## पुढील वाचन {#further-reading} + +- [प्रूफ ऑफ स्टेक FAQ](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [प्रूफ ऑफ स्टेक म्हणजे काय](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [प्रूफ ऑफ स्टेक काय आहे आणि ते का महत्त्वाचे आहे](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [प्रूफ ऑफ स्टेक का (नोव्हेंबर 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [प्रूफ ऑफ स्टेक: मी कमकुवत व्यक्तिनिष्ठतेवर प्रेम कसे करायला शिकलो](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [प्रूफ-ऑफ-स्टेक Ethereum हल्ला आणि संरक्षण](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [प्रूफ ऑफ स्टेक डिझाइन फिलॉसॉफी](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [व्हिडिओ: विटालिक बुटेरिन लेक्स फ्रिडमनला प्रूफ-ऑफ-स्टेक समजावून सांगतात](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## संबंधित विषय {#related-topics} + +- [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow/) +- [प्रूफ-ऑफ-अथॉरिटी](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..1f4c32a7b75 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "प्रूफ-ऑफ-स्टेक Ethereum मधील कीज" +description: "Ethereum च्या प्रूफ-ऑफ-स्टेक कन्सेन्सस मेकॅनिझममध्ये वापरलेल्या कीजचे स्पष्टीकरण" +lang: mr +--- + +Ethereum पब्लिक-प्रायव्हेट की क्रिप्टोग्राफी वापरून वापरकर्त्यांच्या मालमत्तेला सुरक्षित ठेवते. पब्लिक की Ethereum ॲड्रेससाठी आधार म्हणून वापरली जाते—म्हणजेच, ती सर्वसामान्यांसाठी दृश्यमान असते आणि एक युनिक आयडेंटिफायर म्हणून वापरली जाते. प्रायव्हेट (किंवा 'गुप्त') की फक्त अकाउंट मालकासाठीच ॲक्सेसिबल असावी. प्रायव्हेट कीचा वापर व्यवहार आणि डेटा 'साइन' करण्यासाठी केला जातो, जेणेकरून क्रिप्टोग्राफी हे सिद्ध करू शकेल की धारकाने विशिष्ट प्रायव्हेट कीची काही क्रिया मंजूर केली आहे. + +Ethereum च्या कीज [एलिप्टिक-कर्व्ह क्रिप्टोग्राफी](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) वापरून जनरेट केल्या जातात. + +तथापि, जेव्हा Ethereum [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow) वरून [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos) वर स्विच झाले, तेव्हा Ethereum मध्ये एका नवीन प्रकारची की जोडली गेली. मूळ कीज अजूनही पूर्वीसारख्याच काम करतात—अकाउंट सुरक्षित करणाऱ्या एलिप्टिक-कर्व्ह-आधारित कीजमध्ये कोणतेही बदल झाले नाहीत. तथापि, ETH स्टेक करून आणि व्हॅलिडेटर्स चालवून प्रूफ-ऑफ-स्टेकमध्ये सहभागी होण्यासाठी वापरकर्त्यांना एका नवीन प्रकारच्या कीची आवश्यकता होती. ही गरज मोठ्या संख्येने व्हॅलिडेटर्समध्ये अनेक मेसेज पास होण्याशी संबंधित स्केलेबिलिटी आव्हानांमुळे निर्माण झाली, ज्यासाठी अशा क्रिप्टोग्राफिक पद्धतीची आवश्यकता होती जी सहजपणे एकत्रित केली जाऊ शकते, जेणेकरून नेटवर्कला कन्सेन्ससपर्यंत पोहोचण्यासाठी आवश्यक असलेल्या कम्युनिकेशनचे प्रमाण कमी करता येईल. + +या नवीन प्रकारची की [**बोनेह-लिन-शाचम (BLS)** सिग्नेचर स्कीम](https://wikipedia.org/wiki/BLS_digital_signature) वापरते. BLS सिग्नेचर्सचे अतिशय कार्यक्षम एकत्रीकरण सक्षम करते, परंतु एकत्रित वैयक्तिक व्हॅलिडेटर कीजचे रिव्हर्स इंजिनिअरिंग करण्यास देखील अनुमती देते आणि व्हॅलिडेटर्समधील क्रिया व्यवस्थापित करण्यासाठी आदर्श आहे. + +## व्हॅलिडेटर कीजचे दोन प्रकार {#two-types-of-keys} + +प्रूफ-ऑफ-स्टेकवर स्विच करण्यापूर्वी, Ethereum वापरकर्त्यांकडे त्यांच्या फंडांमध्ये ऍक्सेस करण्यासाठी फक्त एकच एलिप्टिक-कर्व्ह-आधारित प्रायव्हेट की होती. प्रूफ-ऑफ-स्टेकच्या परिचयाने, सोलो स्टेकर बनू इच्छिणाऱ्या वापरकर्त्यांना एक **व्हॅलिडेटर की** आणि एक **विथड्रॉवल की** देखील आवश्यक होती. + +### व्हॅलिडेटर की {#validator-key} + +व्हॅलिडेटर साइनिंग कीमध्ये दोन घटक असतात: + +- व्हॅलिडेटर **प्रायव्हेट** की +- व्हॅलिडेटर **पब्लिक** की + +व्हॅलिडेटर प्रायव्हेट कीचा उद्देश ब्लॉक प्रस्ताव आणि अटेस्टेशन्स यांसारख्या ऑनचेन ऑपरेशन्सना साइन करणे हा आहे. यामुळे, या कीज हॉट वॉलेटमध्ये ठेवल्या पाहिजेत. + +या लवचिकतेचा फायदा असा आहे की व्हॅलिडेटर साइनिंग की एका डिव्हाइसवरून दुसऱ्या डिव्हाइसवर खूप वेगाने हलवता येतात, तथापि, जर त्या हरवल्या किंवा चोरीला गेल्या, तर चोर काही मार्गांनी **दुर्भावनापूर्णपणे वागू** शकतो: + +- याद्वारे व्हॅलिडेटरला स्लॅश करणे: + - प्रपोजर म्हणून एकाच स्लॉटसाठी दोन भिन्न बीकन ब्लॉक्स साइन करणे + - अटेस्टर म्हणून असे अटेस्टेशन साइन करणे जे दुसऱ्याला "सराउंड" करते + - अटेस्टर म्हणून समान टार्गेट असलेली दोन भिन्न अटेस्टेशन्स साइन करणे +- स्वैच्छिक एक्झिटसाठी भाग पाडणे, ज्यामुळे व्हॅलिडेटर स्टेक करणे थांबवतो, आणि त्याच्या ETH बॅलन्सचा ऍक्सेस विथड्रॉवल की मालकाला मिळतो + +जेव्हा वापरकर्ता स्टेकिंग डिपॉझिट कॉन्ट्रॅक्टमध्ये ETH जमा करतो तेव्हा **व्हॅलिडेटर पब्लिक की** व्यवहार डेटामध्ये समाविष्ट केली जाते. याला _डिपॉझिट डेटा_ म्हणून ओळखले जाते आणि ते Ethereum ला व्हॅलिडेटर ओळखण्याची परवानगी देते. + +### विथड्रॉवल क्रेडेन्शियल्स {#withdrawal-credentials} + +प्रत्येक व्हॅलिडेटरकडे _विथड्रॉवल क्रेडेन्शियल्स_ म्हणून ओळखली जाणारी एक प्रॉपर्टी असते. या 32-बाईट फील्डचा पहिला बाईट अकाउंटचा प्रकार ओळखतो: `0x00` मूळ BLS (प्री-शापेला, नॉन-विथड्रॉएबल) क्रेडेन्शियल्स दर्शवते, `0x01` एका एक्झिक्युशन ॲड्रेसकडे पॉइंट करणारी लेगसी क्रेडेन्शियल्स दर्शवते, आणि `0x02` आधुनिक कंपाउंडिंग क्रेडेन्शियल प्रकार दर्शवते. + +`0x00` BLS कीज असलेल्या व्हॅलिडेटर्सना अतिरिक्त बॅलन्स पेमेंट किंवा स्टेकिंगमधून पूर्ण विथड्रॉवल सक्रिय करण्यासाठी या क्रेडेन्शियल्सना एका एक्झिक्युशन ॲड्रेसकडे पॉइंट करण्यासाठी अपडेट करणे आवश्यक आहे. हे सुरुवातीच्या की जनरेशन दरम्यान डिपॉझिट डेटामध्ये एक्झिक्युशन ॲड्रेस देऊन केले जाऊ शकते, _किंवा_ नंतरच्या वेळी विथड्रॉवल की वापरून `BLSToExecutionChange` मेसेज साइन आणि ब्रॉडकास्ट करून केले जाऊ शकते. + +[व्हॅलिडेटर विथड्रॉवल क्रेडेन्शियल्सवर अधिक माहिती](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### विथड्रॉवल की {#withdrawal-key} + +जर सुरुवातीच्या डिपॉझिट दरम्यान सेट केले नसेल तर, विथड्रॉवल क्रेडेन्शियल्सना एक्झिक्युशन ॲड्रेसकडे पॉइंट करण्यासाठी अपडेट करण्याकरिता विथड्रॉवल कीची आवश्यकता असेल. यामुळे अतिरिक्त बॅलन्स पेमेंटवर प्रक्रिया सुरू करणे शक्य होईल, आणि वापरकर्त्यांना त्यांचे स्टेक केलेले ETH पूर्णपणे विथड्रॉ करण्याची परवानगी देखील मिळेल. + +व्हॅलिडेटर कीजप्रमाणेच, विथड्रॉवल कीमध्ये देखील दोन घटक असतात: + +- विथड्रॉवल **प्रायव्हेट** की +- विथड्रॉवल **पब्लिक** की + +विथड्रॉवल क्रेडेन्शियल्सना `0x01` प्रकारात अपडेट करण्यापूर्वी ही की गमावणे म्हणजे व्हॅलिडेटरच्या बॅलन्सचा ऍक्सेस गमावणे. व्हॅलिडेटर अजूनही अटेस्टेशन्स आणि ब्लॉक्स साइन करू शकतो, कारण या क्रियांसाठी व्हॅलिडेटरच्या प्रायव्हेट कीची आवश्यकता असते, तथापि, विथड्रॉवल कीज गमावल्यास थोडे किंवा काहीही प्रोत्साहन राहत नाही. + +व्हॅलिडेटर कीज Ethereum अकाउंट कीजपासून वेगळे केल्याने एकाच वापरकर्त्याद्वारे अनेक व्हॅलिडेटर्स चालवणे शक्य होते. + +![व्हॅलिडेटर की स्केमॅटिक](validator-key-schematic.png) + +**टीप**: स्टेकिंग कर्तव्यांमधून बाहेर पडण्यासाठी आणि व्हॅलिडेटरचा बॅलन्स विथड्रॉ करण्यासाठी सध्या व्हॅलिडेटर कीने [स्वैच्छिक एक्झिट मेसेज (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) साइन करणे आवश्यक आहे. तथापि, [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) हा एक प्रस्ताव आहे जो वापरकर्त्याला भविष्यात विथड्रॉवल कीने एक्झिट मेसेज साइन करून व्हॅलिडेटरचे एक्झिट सुरू करण्याची आणि त्याचा बॅलन्स विथड्रॉ करण्याची परवानगी देईल. यामुळे विश्वासाची गृहीतके कमी होतील कारण जे स्टेकर्स [स्टेकिंग-ॲज-अ-सर्व्हिस प्रोव्हायडर्स](/staking/saas/#what-is-staking-as-a-service) यांना ETH डेलीगेट करतात, त्यांना त्यांच्या फंडांवर नियंत्रण ठेवता येईल. + +## सीड फ्रेजमधून कीज मिळवणे {#deriving-keys-from-seed} + +जर प्रत्येक 32 ETH स्टेकसाठी 2 पूर्णपणे स्वतंत्र कीजचा नवीन संच आवश्यक असेल, तर की मॅनेजमेंट लवकरच अव्यवहार्य होईल, विशेषतः अनेक व्हॅलिडेटर्स चालवणाऱ्या वापरकर्त्यांसाठी. त्याऐवजी, एकाच कॉमन सीक्रेटमधून अनेक व्हॅलिडेटर कीज मिळवल्या जाऊ शकतात आणि ते एकच सीक्रेट स्टोअर केल्याने अनेक व्हॅलिडेटर कीजचा ऍक्सेस मिळतो. + +[नेमोनिक्स](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) आणि पाथ ही प्रमुख वैशिष्ट्ये आहेत जी वापरकर्त्यांना त्यांच्या वॉलेटमध्ये [ऍक्सेस](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) करताना अनेकदा आढळतात. नेमोनिक हा शब्दांचा एक क्रम आहे जो प्रायव्हेट कीसाठी प्रारंभिक सीड म्हणून काम करतो. अतिरिक्त डेटासोबत एकत्रित केल्यावर, नेमोनिक एक हॅश जनरेट करतो ज्याला 'मास्टर की' म्हणून ओळखले जाते. याला झाडाचे मूळ मानले जाऊ शकते. या मूळातून फांद्या नंतर एका हायरार्किकल पाथचा वापर करून मिळवल्या जाऊ शकतात, जेणेकरून चाइल्ड नोड्स त्यांच्या पॅरेंट नोडच्या हॅश आणि ट्रीमधील त्यांच्या इंडेक्सचे कॉम्बिनेशन म्हणून अस्तित्वात राहू शकतील. नेमोनिक-आधारित की जनरेशनसाठी [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) आणि [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) मानकांविषयी वाचा. + +या पाथ्सची रचना खालीलप्रमाणे आहे, जी हार्डवेअर वॉलेट्सशी संवाद साधलेल्या वापरकर्त्यांना परिचित असेल: + +``` +m/44'/60'/0'/0` +``` + +या पाथमधील स्लॅश प्रायव्हेट कीचे घटक खालीलप्रमाणे वेगळे करतात: + +``` +मास्टर_की / उद्देश / कॉइन_प्रकार / अकाउंट / बदल / ॲड्रेस_इंडेक्स +``` + +हे लॉजिक वापरकर्त्यांना एकाच **नेमोनिक फ्रेज**शी शक्य तितके व्हॅलिडेटर्स जोडण्यास सक्षम करते कारण ट्री रूट कॉमन असू शकतो, आणि फांद्यांवर वेगळेपण येऊ शकते. वापरकर्ता नेमोनिक फ्रेजमधून **कितीही कीज मिळवू** शकतो. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +प्रत्येक फांदी `/` ने वेगळी केली आहे, म्हणून `m/2` म्हणजे मास्टर कीने सुरुवात करून फांदी 2 फॉलो करणे. खालील स्केमॅटिकमध्ये, तीन विथड्रॉवल कीज स्टोअर करण्यासाठी एकाच नेमोनिक फ्रेजचा वापर केला जातो, प्रत्येकी दोन संबंधित व्हॅलिडेटर्ससोबत. + +![व्हॅलिडेटर की लॉजिक](multiple-keys.png) + +## पुढील वाचन {#further-reading} + +- [कार्ल बीखुइझेनचा Ethereum फाउंडेशन ब्लॉग पोस्ट](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 की जनरेशन](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: एक्झिक्युशन लेयर ट्रिगर्ड एक्झिट्स](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [मोठ्या प्रमाणावर की मॅनेजमेंट](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..59a72d6f299 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "प्रूफ-ऑफ-स्टेक विरुद्ध प्रूफ-ऑफ-वर्क" +description: "Ethereum च्या प्रूफ-ऑफ-स्टेक आणि प्रूफ-ऑफ-वर्क आधारित सहमती यंत्रणेमधील तुलना" +lang: mr +--- + +जेव्हा Ethereum लाँच झाले, तेव्हा Ethereum ला सुरक्षित ठेवण्यासाठी त्यावर विश्वास ठेवण्यापूर्वी प्रूफ-ऑफ-स्टेकला अजूनही खूप संशोधन आणि विकासाची आवश्यकता होती. प्रूफ-ऑफ-वर्क ही एक सोपी यंत्रणा होती जी बिटकॉइनद्वारे आधीच सिद्ध झाली होती, याचा अर्थ कोअर डेव्हलपर्स Ethereum लाँच करण्यासाठी लगेचच तिची अंमलबजावणी करू शकत होते. प्रूफ-ऑफ-स्टेकला त्या टप्प्यापर्यंत विकसित करण्यासाठी आणखी आठ वर्षे लागली जिथे त्याची अंमलबजावणी करता येईल. + +हे पृष्ठ Ethereum च्या प्रूफ-ऑफ-वर्कमधून प्रूफ-ऑफ-स्टेकवर स्विच करण्यामागील तर्क आणि त्यात सामील असलेले फायदे-तोटे स्पष्ट करते. + +## सुरक्षा {#security} + +Ethereum चे संशोधक प्रूफ-ऑफ-वर्कपेक्षा प्रूफ-ऑफ-स्टेकला अधिक सुरक्षित मानतात. तथापि, हे नुकतेच खऱ्या Ethereum मेननेटसाठी लागू केले गेले आहे आणि प्रूफ-ऑफ-वर्कपेक्षा कमी वेळ-सिद्ध आहे. खालील विभाग प्रूफ-ऑफ-वर्कच्या तुलनेत प्रूफ-ऑफ-स्टेकच्या सुरक्षा मॉडेलचे फायदे आणि तोटे यावर चर्चा करतात. + +### हल्ला करण्याची किंमत {#cost-to-attack} + +प्रूफ-ऑफ-स्टेकमध्ये, व्हॅलिडेटर्सना स्मार्ट कॉन्ट्रॅक्टमध्ये किमान 32 ETH एस्क्रो (\"स्टेक\") करणे आवश्यक आहे. Ethereum गैरवर्तन करणाऱ्या व्हॅलिडेटर्सना शिक्षा देण्यासाठी स्टेक केलेला इथर नष्ट करू शकते. सहमतीवर येण्यासाठी, एकूण स्टेक केलेल्या इथरपैकी किमान 66% ने ब्लॉकच्या विशिष्ट संचाच्या बाजूने मतदान करणे आवश्यक आहे. स्टेकच्या >=66% द्वारे मतदान केलेले ब्लॉक्स \"अंतिम\" (finalized) बनतात, याचा अर्थ ते काढले किंवा पुनर्रचित केले जाऊ शकत नाहीत. + +नेटवर्कवर हल्ला करणे म्हणजे साखळीला अंतिम होण्यापासून रोखणे किंवा कॅनोनिकल साखळीमध्ये ब्लॉकची एक विशिष्ट संघटना सुनिश्चित करणे, ज्यामुळे आक्रमणकर्त्याला कसा तरी फायदा होतो. यासाठी आक्रमणकर्त्याला मोठ्या प्रमाणात इथर जमा करून आणि थेट त्याच्यासह मतदान करून किंवा प्रामाणिक व्हॅलिडेटर्सना विशिष्ट प्रकारे मतदान करण्यासाठी फसवून प्रामाणिक सहमतीचा मार्ग वळवावा लागतो. प्रामाणिक व्हॅलिडेटर्सना फसवणारे अत्याधुनिक, कमी-संभाव्यतेचे हल्ले वगळता, Ethereum वर हल्ला करण्याची किंमत म्हणजे आक्रमणकर्त्याला त्यांच्या बाजूने सहमतीवर प्रभाव टाकण्यासाठी जमा कराव्या लागणाऱ्या स्टेकची किंमत. + +हल्ल्याची सर्वात कमी किंमत एकूण स्टेकच्या >33% आहे. एकूण स्टेकच्या >33% धारण करणारा आक्रमणकर्ता फक्त ऑफलाइन जाऊन अंतिम निश्चितीमध्ये (finality) विलंब घडवून आणू शकतो. नेटवर्कसाठी ही एक तुलनेने किरकोळ समस्या आहे कारण \"निष्क्रियता लीक\" (inactivity leak) नावाची एक यंत्रणा आहे जी ऑफलाइन व्हॅलिडेटर्सकडून स्टेक लीक करते, जोपर्यंत ऑनलाइन बहुमत स्टेकच्या 66% चे प्रतिनिधित्व करत नाही आणि साखळी पुन्हा अंतिम करू शकत नाही. हे सैद्धांतिकदृष्ट्या शक्य आहे की आक्रमणकर्ता एकूण स्टेकच्या 33% पेक्षा थोडे जास्त घेऊन दुहेरी अंतिम निश्चिती (double finality) घडवून आणू शकतो, जेव्हा त्यांना ब्लॉक प्रोड्यूसर बनण्यास सांगितले जाते तेव्हा एकाऐवजी दोन ब्लॉक तयार करून आणि नंतर त्यांच्या सर्व व्हॅलिडेटर्ससह दुहेरी-मतदान करून. प्रत्येक फोर्कला प्रत्येक ब्लॉक प्रथम पाहण्यासाठी उर्वरित प्रामाणिक व्हॅलिडेटर्सपैकी फक्त 50% आवश्यक असतात, म्हणून जर ते त्यांचे संदेश योग्य वेळी पाठवण्यात यशस्वी झाले, तर ते दोन्ही फोर्क अंतिम करू शकतील. याची यशस्वी होण्याची शक्यता कमी आहे, परंतु जर आक्रमणकर्ता दुहेरी-अंतिम निश्चिती (double-finality) घडवून आणू शकला, तर Ethereum समुदायाला एका फोर्कचे अनुसरण करण्याचा निर्णय घ्यावा लागेल, ज्या प्रकरणात आक्रमणकर्त्याच्या व्हॅलिडेटर्सना दुसऱ्या फोर्कवर नक्कीच स्लॅश केले जाईल. + +एकूण स्टेकच्या >33% सह, आक्रमणकर्त्याला Ethereum नेटवर्कवर किरकोळ (अंतिम निश्चितीमध्ये विलंब) किंवा अधिक गंभीर (दुहेरी अंतिम निश्चिती) परिणाम करण्याची संधी असते. नेटवर्कवर 14,000,000 पेक्षा जास्त ETH स्टेक केलेले असताना आणि $1000/ETH च्या प्रातिनिधिक किंमतीसह, हे हल्ले करण्यासाठी किमान खर्च `1000 x 14,000,000 x 0.33 = $4,620,000,000` आहे. आक्रमणकर्ता स्लॅशिंगद्वारे हे पैसे गमावेल आणि नेटवर्कमधून बाहेर काढला जाईल. पुन्हा हल्ला करण्यासाठी, त्यांना स्टेकच्या >33% (पुन्हा) जमा करावे लागेल आणि ते (पुन्हा) बर्न करावे लागेल. नेटवर्कवर हल्ला करण्याच्या प्रत्येक प्रयत्नाची किंमत >$4.6 अब्ज असेल ($1000/ETH आणि 14M ETH स्टेक केलेले असताना). आक्रमणकर्त्याला स्लॅश केल्यावर नेटवर्कमधून बाहेर काढले जाते, आणि त्यांना पुन्हा सामील होण्यासाठी सक्रियकरण रांगेत (activation queue) सामील व्हावे लागते. याचा अर्थ पुनरावृत्ती हल्ल्याचा दर केवळ आक्रमणकर्ता एकूण स्टेकच्या >33% जमा करू शकण्याच्या दरापुरता मर्यादित नाही, तर त्यांच्या सर्व व्हॅलिडेटर्सना नेटवर्कवर ऑनबोर्ड करण्यासाठी लागणाऱ्या वेळेवरही अवलंबून आहे. प्रत्येक वेळी आक्रमणकर्ता हल्ला करतो, तेव्हा ते अधिक गरीब होतात आणि उर्वरित समुदाय परिणामी पुरवठा धक्क्यामुळे (supply shock) श्रीमंत होतो. + +इतर हल्ले, जसे की 51% हल्ले किंवा एकूण स्टेकच्या 66% सह अंतिम निश्चिती रिव्हर्जन (finality reversion), यासाठी लक्षणीयरीत्या अधिक ETH आवश्यक आहे आणि ते आक्रमणकर्त्यासाठी खूपच महाग आहेत. + +याची प्रूफ-ऑफ-वर्कशी तुलना करा. प्रूफ-ऑफ-वर्क Ethereum वर हल्ला करण्याची किंमत एकूण नेटवर्क हॅश रेटच्या >50% सातत्याने मालकीची असण्याची किंमत होती. यामध्ये इतर मायनर्सना सातत्याने प्रूफ-ऑफ-वर्क सोल्यूशन्सची गणना करण्यासाठी मागे टाकण्याकरिता पुरेशी संगणकीय शक्ती मिळवण्यासाठी हार्डवेअर आणि चालू खर्चाचा समावेश होता. Ethereum चे मायनिंग मुख्यतः ASICs ऐवजी GPUs वापरून केले जात होते, ज्यामुळे खर्च कमी राहिला (जरी Ethereum प्रूफ-ऑफ-वर्कवर राहिले असते, तर ASIC मायनिंग अधिक लोकप्रिय झाले असते). प्रूफ-ऑफ-वर्क Ethereum नेटवर्कवर हल्ला करण्यासाठी प्रतिस्पर्ध्याला भरपूर हार्डवेअर खरेदी करावे लागेल आणि ते चालवण्यासाठी विजेचे पैसे द्यावे लागतील, परंतु एकूण खर्च हल्ला सुरू करण्यासाठी पुरेसे ETH जमा करण्यासाठी लागणाऱ्या खर्चापेक्षा कमी असेल. प्रूफ-ऑफ-स्टेकपेक्षा प्रूफ-ऑफ-वर्कवर 51% हल्ला ~[20x कमी](https://youtu.be/1m12zgJ42dI?t=1562) महाग असतो. जर हल्ला ओळखला गेला आणि त्यांच्या बदलांना काढून टाकण्यासाठी साखळी हार्ड-फोर्क केली गेली, तर आक्रमणकर्ता नवीन फोर्कवर हल्ला करण्यासाठी वारंवार तेच हार्डवेअर वापरू शकतो. + +### गुंतागुंत {#complexity} + +प्रूफ-ऑफ-स्टेक हे प्रूफ-ऑफ-वर्कपेक्षा खूपच गुंतागुंतीचे आहे. हा प्रूफ-ऑफ-वर्कच्या बाजूने एक मुद्दा असू शकतो कारण सोप्या प्रोटोकॉलमध्ये चुकून बग्स किंवा अनपेक्षित परिणाम आणणे अधिक कठीण आहे. तथापि, अनेक वर्षांच्या संशोधन आणि विकास, सिम्युलेशन आणि टेस्टनेट अंमलबजावणीद्वारे ही गुंतागुंत कमी केली गेली आहे. प्रूफ-ऑफ-स्टेक प्रोटोकॉल पाच स्वतंत्र संघांनी (एक्झिक्युशन आणि कन्सेंसस लेयर प्रत्येकावर) पाच प्रोग्रामिंग भाषांमध्ये स्वतंत्रपणे लागू केला आहे, जो क्लायंट बग्सविरुद्ध लवचिकता प्रदान करतो. + +प्रूफ-ऑफ-स्टेक सहमती लॉजिक सुरक्षितपणे विकसित आणि चाचणी करण्यासाठी, Ethereum मेननेटवर प्रूफ-ऑफ-स्टेक लागू होण्याच्या दोन वर्षांपूर्वी बीकन चेन लाँच करण्यात आली होती. बीकन चेनने प्रूफ-ऑफ-स्टेक चाचणीसाठी सँडबॉक्स म्हणून काम केले, कारण ती एक लाइव्ह ब्लॉकचेन होती जी प्रूफ-ऑफ-स्टेक सहमती लॉजिक लागू करत होती परंतु वास्तविक Ethereum व्यवहारांना स्पर्श न करता - प्रभावीपणे फक्त स्वतःवरच सहमतीवर येत होती. एकदा हे पुरेसा काळ स्थिर आणि बग-मुक्त झाल्यावर, बीकन चेन Ethereum मेननेटसोबत \"विलीन\" (merged) करण्यात आली. या सर्वांनी प्रूफ-ऑफ-स्टेकची गुंतागुंत त्या टप्प्यापर्यंत कमी करण्यास हातभार लावला की अनपेक्षित परिणाम किंवा क्लायंट बग्सचा धोका खूप कमी होता. + +### हल्ल्याची शक्यता {#attack-surface} + +प्रूफ-ऑफ-स्टेक हे प्रूफ-ऑफ-वर्कपेक्षा अधिक गुंतागुंतीचे आहे, याचा अर्थ हाताळण्यासाठी अधिक संभाव्य हल्ल्याचे मार्ग (attack vectors) आहेत. क्लायंटना जोडणाऱ्या एका पीअर-टू-पीअर नेटवर्कऐवजी, दोन आहेत, प्रत्येक एक वेगळा प्रोटोकॉल लागू करतो. प्रत्येक स्लॉटमध्ये ब्लॉक प्रस्तावित करण्यासाठी एका विशिष्ट व्हॅलिडेटरची पूर्व-निवड केल्याने डिनायल-ऑफ-सर्व्हिसची शक्यता निर्माण होते जिथे मोठ्या प्रमाणात नेटवर्क ट्रॅफिक त्या विशिष्ट व्हॅलिडेटरला ऑफलाइन करते. + +आक्रमणकर्त्यांसाठी त्यांचे ब्लॉक्स किंवा साक्षांकन (attestations) सोडण्याची वेळ काळजीपूर्वक साधण्याचे मार्ग देखील आहेत जेणेकरून ते प्रामाणिक नेटवर्कच्या विशिष्ट प्रमाणात प्राप्त होतील, ज्यामुळे त्यांना विशिष्ट मार्गांनी मतदान करण्यास प्रभावित करता येईल. शेवटी, आक्रमणकर्ता फक्त स्टेक करण्यासाठी पुरेसे ETH जमा करू शकतो आणि सहमती यंत्रणेवर (consensus mechanism) वर्चस्व गाजवू शकतो. या प्रत्येक [हल्ल्याच्या मार्गांशी संबंधित संरक्षण](/developers/docs/consensus-mechanisms/pos/attack-and-defense) आहे, परंतु प्रूफ-ऑफ-वर्क अंतर्गत त्यांचे संरक्षण करण्याची गरज नसते. + +## विकेंद्रीकरण {#decentralization} + +प्रूफ-ऑफ-स्टेक हे प्रूफ-ऑफ-वर्कपेक्षा अधिक विकेंद्रित आहे कारण मायनिंग हार्डवेअरच्या शस्त्रास्त्र शर्यतीमुळे व्यक्ती आणि लहान संस्थांना बाहेर पडावे लागते. कोणीही तांत्रिकदृष्ट्या माफक हार्डवेअरसह मायनिंग सुरू करू शकत असले तरी, संस्थात्मक मायनिंग ऑपरेशन्सच्या तुलनेत त्यांना कोणतेही बक्षीस मिळण्याची शक्यता नगण्य आहे. प्रूफ-ऑफ-स्टेकसह, स्टेक‍िंगचा खर्च आणि त्या स्टेकवरील परताव्याची टक्केवारी प्रत्येकासाठी समान आहे. सध्या व्हॅलिडेटर चालवण्यासाठी 32 ETH खर्च येतो. + +दुसरीकडे, लिक्विड स्टेक‍िंग डेरिव्हेटिव्ह्जच्या शोधाने केंद्रीकरणाची चिंता निर्माण केली आहे कारण काही मोठे प्रदाते मोठ्या प्रमाणात स्टेक केलेले ETH व्यवस्थापित करतात. ही एक समस्या आहे आणि ती शक्य तितक्या लवकर दुरुस्त करणे आवश्यक आहे, परंतु ती दिसते त्यापेक्षा अधिक सूक्ष्म आहे. केंद्रीकृत स्टेक‍िंग प्रदात्यांचे व्हॅलिडेटर्सवर नेहमीच केंद्रीकृत नियंत्रण नसते - अनेकदा हा ETH चा एक केंद्रीय पूल तयार करण्याचा एक मार्ग असतो जिथे अनेक स्वतंत्र नोड ऑपरेटर प्रत्येक सहभागीला स्वतःचे 32 ETH आवश्यक न ठेवता स्टेक करू शकतात. + +Ethereum साठी सर्वोत्तम पर्याय म्हणजे व्हॅलिडेटर्स घरगुती संगणकांवर स्थानिकरित्या चालवणे, ज्यामुळे विकेंद्रीकरण जास्तीत जास्त होते. यामुळेच Ethereum नोड/व्हॅलिडेटर चालवण्यासाठी हार्डवेअर आवश्यकता वाढवणाऱ्या बदलांना विरोध करते. + +## टिकावूपणा {#sustainability} + +प्रूफ-ऑफ-स्टेक हा ब्लॉकचेन सुरक्षित करण्याचा कमी कार्बन-उत्सर्जन करणारा मार्ग आहे. प्रूफ-ऑफ-वर्क अंतर्गत मायनर्स ब्लॉक माईन करण्याच्या हक्कासाठी स्पर्धा करतात. जेव्हा मायनर्स जलद गतीने गणना करू शकतात तेव्हा ते अधिक यशस्वी होतात, ज्यामुळे हार्डवेअर आणि ऊर्जा वापरामध्ये गुंतवणुकीला प्रोत्साहन मिळते. हे Ethereum ने प्रूफ-ऑफ-स्टेकवर स्विच करण्यापूर्वी पाहिले गेले. प्रूफ-ऑफ-स्टेकमध्ये संक्रमण होण्यापूर्वी, Ethereum अंदाजे 78 TWh/yr वापरत होते - जे एका लहान देशाएवढे आहे. तथापि, प्रूफ-ऑफ-स्टेकवर स्विच केल्याने हा ऊर्जा खर्च ~99.98% ने कमी झाला. प्रूफ-ऑफ-स्टेकने Ethereum ला एक ऊर्जा-कार्यक्षम, कमी कार्बन उत्सर्जन करणारे प्लॅटफॉर्म बनवले. + +[Ethereum च्या ऊर्जा वापराविषयी अधिक](/energy-consumption) + +## जारी करणे {#issuance} + +प्रूफ-ऑफ-स्टेक Ethereum त्याच्या सुरक्षेसाठी प्रूफ-ऑफ-वर्क Ethereum पेक्षा खूप कमी कॉइन्स जारी करून पैसे देऊ शकते कारण व्हॅलिडेटर्सना उच्च वीज खर्च भरावा लागत नाही. परिणामी, जेव्हा मोठ्या प्रमाणात ETH बर्न केले जातात तेव्हा ETH त्याची चलनवाढ कमी करू शकते किंवा डिफ्लेशनरी ( चलनघट ) देखील होऊ शकते. कमी चलनवाढ पातळीचा अर्थ असा आहे की Ethereum ची सुरक्षा प्रूफ-ऑफ-वर्क अंतर्गत होती त्यापेक्षा स्वस्त आहे. + +## तुम्ही पाहून शिकणारे आहात का? {#visual-learner} + +पहा जस्टिन ड्रेक प्रूफ-ऑफ-वर्कपेक्षा प्रूफ-ऑफ-स्टेकचे फायदे स्पष्ट करत आहेत: + + + +## पुढील वाचन {#further-reading} + +- [विटालिकचे प्रूफ-ऑफ-स्टेक डिझाइन तत्वज्ञान](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [विटालिकचे प्रूफ-ऑफ-स्टेक FAQs](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [\"सोप्या भाषेत स्पष्ट केलेले\" pos विरुद्ध pow वरील व्हिडिओ](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..d6ea072c3d4 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "प्रूफ-ऑफ-स्टेक बक्षिसे आणि दंड" +description: "प्रूफ-ऑफ-स्टेक Ethereum मधील प्रोटोकॉलमधील प्रोत्साहनांबद्दल जाणून घ्या." +lang: mr +--- + +Ethereum त्याच्या मूळ क्रिप्टोकरन्सी, ईथर (ETH) वापरून सुरक्षित केले आहे. नोड ऑपरेटर्स जे ब्लॉक्स प्रमाणित करण्यात आणि चेनच्या हेडची ओळख पटवण्यात सहभागी होऊ इच्छितात, ते Ethereum वरील [डिपॉझिट कॉन्ट्रॅक्ट](/staking/deposit-contract/) मध्ये ईथर जमा करतात. त्यांना नंतर व्हॅलिडेटर सॉफ्टवेअर चालवण्यासाठी ईथरमध्ये पैसे दिले जातात, जे पिअर-टू-पिअर नेटवर्कवर मिळालेल्या नवीन ब्लॉक्सची वैधता तपासते आणि चेनच्या हेडची ओळख पटवण्यासाठी फोर्क-चॉइस अल्गोरिदम लागू करते. + +व्हॅलिडेटरसाठी दोन प्राथमिक भूमिका आहेत: १) नवीन ब्लॉक्स तपासणे आणि ते वैध असल्यास त्यांना “साक्षांकित करणे”, २) एकूण व्हॅलिडेटर पूलमधून यादृच्छिकपणे निवडल्यावर नवीन ब्लॉक्स प्रस्तावित करणे. जर व्हॅलिडेटर विचारले असता यापैकी कोणतेही कार्य करण्यास अयशस्वी ठरले, तर ते ईथर पेआउट चुकवतात. व्हॅलिडेटर्सना काहीवेळा सिग्नेचर एग्रीगेशन आणि सिंक कमिटीमध्ये सहभागी होण्याचे कामही दिले जाते. + +अशा काही कृती देखील आहेत ज्या चुकून करणे खूप कठीण आहे आणि त्या काही दुर्भावनापूर्ण हेतू दर्शवतात, जसे की एकाच स्लॉटसाठी अनेक ब्लॉक्स प्रस्तावित करणे किंवा एकाच स्लॉटसाठी अनेक ब्लॉक्सना साक्षांकित करणे. हे “स्लॅशेबल” वर्तन आहेत ज्यामुळे व्हॅलिडेटरला नेटवर्कमधून काढून टाकण्यापूर्वी काही प्रमाणात ईथर (1 ETH पर्यंत) बर्न केले जाते, ज्याला 36 दिवस लागतात. स्लॅश केलेल्या व्हॅलिडेटरचा ईथर एक्झिट कालावधीत हळूहळू कमी होत जातो, परंतु 18 व्या दिवशी त्यांना “कोरिलेशन पेनल्टी” मिळते, जी त्याच वेळी अधिक व्हॅलिडेटर्सना स्लॅश केल्यावर मोठी असते. म्हणूनच कन्सेन्सस मेकॅनिझमची प्रोत्साहन रचना प्रामाणिकपणासाठी पैसे देते आणि वाईट कलाकारांना शिक्षा देते. + +सर्व बक्षिसे आणि दंड प्रत्येक इपॉकमध्ये एकदा लागू केले जातात. + +अधिक माहितीसाठी पुढे वाचा... + +## बक्षिसे आणि दंड {#rewards} + +### पुरस्कार {#rewards} + +जेव्हा व्हॅलिडेटर्स बहुसंख्य इतर व्हॅलिडेटर्सशी सुसंगत मते देतात, ब्लॉक्स प्रस्तावित करतात, आणि सिंक कमिटीमध्ये सहभागी होतात, तेव्हा त्यांना बक्षिसे मिळतात. प्रत्येक इपॉकमधील बक्षिसांचे मूल्य `base_reward` वरून मोजले जाते. हे मूळ एकक आहे ज्यावरून इतर बक्षिसे मोजली जातात. `base_reward` हे प्रति इपॉक इष्टतम परिस्थितीत एका व्हॅलिडेटरला मिळालेले सरासरी बक्षीस दर्शवते. हे व्हॅलिडेटरच्या प्रभावी बॅलन्स आणि सक्रिय व्हॅलिडेटर्सच्या एकूण संख्येवरून खालीलप्रमाणे मोजले जाते: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +जिथे `base_reward_factor` 64 आहे, `base_rewards_per_epoch` 4 आहे आणि `sum(active balance)` सर्व सक्रिय व्हॅलिडेटर्समधील एकूण स्टेक केलेला ईथर आहे. + +याचा अर्थ असा की बेस रिवॉर्ड व्हॅलिडेटरच्या प्रभावी बॅलन्सच्या प्रमाणात आहे आणि नेटवर्कवरील व्हॅलिडेटर्सच्या संख्येच्या व्यस्त प्रमाणात आहे. व्हॅलिडेटर्स जितके जास्त, तितके एकूण इश्युअन्स जास्त (`sqrt(N)` प्रमाणे) पण प्रति व्हॅलिडेटर `base_reward` तितका लहान (`1/sqrt(N)` प्रमाणे). हे घटक स्टेकिंग नोडसाठी APR ला प्रभावित करतात. [विटालिकच्या नोट्स](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards) मध्ये यामागील तर्क वाचा. + +एकूण बक्षीस नंतर पाच घटकांच्या बेरजेनुसार मोजले जाते, ज्यापैकी प्रत्येकाचे एक वेटिंग असते जे ठरवते की प्रत्येक घटक एकूण बक्षिसामध्ये किती भर घालतो. हे घटक आहेत: + +``` +१. सोर्स व्होट: व्हॅलिडेटरने योग्य सोर्स चेकपॉइंटसाठी वेळेवर मत दिले आहे +२. टार्गेट व्होट: व्हॅलिडेटरने योग्य टार्गेट चेकपॉइंटसाठी वेळेवर मत दिले आहे +३. हेड व्होट: व्हॅलिडेटरने योग्य हेड ब्लॉकसाठी वेळेवर मत दिले आहे +४. सिंक कमिटी रिवॉर्ड: व्हॅलिडेटरने सिंक कमिटीमध्ये भाग घेतला आहे +५. प्रपोजर रिवॉर्ड: व्हॅलिडेटरने योग्य स्लॉटमध्ये ब्लॉक प्रस्तावित केला आहे +``` + +प्रत्येक घटकासाठी वेटिंग खालीलप्रमाणे आहेत: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +या वजनांची बेरीज 64 आहे. लागू होणाऱ्या वजनांची बेरीज 64 ने भागून बक्षीस मोजले जाते. एखादा व्हॅलिडेटर ज्याने वेळेवर सोर्स, टार्गेट आणि हेड व्होट्स दिले आहेत, ब्लॉक प्रस्तावित केला आहे आणि सिंक कमिटीमध्ये भाग घेतला आहे, त्याला `64/64 * base_reward == base_reward` मिळू शकते. तथापि, एक व्हॅलिडेटर सहसा ब्लॉक प्रपोजर नसतो, त्यामुळे त्याचे जास्तीत जास्त बक्षीस `64-8 /64 * base_reward == 7/8 * base_reward` आहे. जे व्हॅलिडेटर ब्लॉक प्रपोजर किंवा सिंक कमिटीमध्ये नाहीत, ते `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` मिळवू शकतात. + +जलद साक्षांकनांना प्रोत्साहन देण्यासाठी अतिरिक्त बक्षीस जोडले जाते. हे `inclusion_delay_reward` आहे. याचे मूल्य `base_reward` ला `1/delay` ने गुणल्यावर येणाऱ्या मूल्याच्या बरोबरीचे असते, जिथे `delay` म्हणजे ब्लॉक प्रस्ताव आणि साक्षांकन यांना वेगळे करणाऱ्या स्लॉट्सची संख्या आहे. उदाहरणार्थ, जर साक्षांकन ब्लॉक प्रस्तावाच्या एका स्लॉटमध्ये सादर केले गेले, तर साक्षांकित करणाऱ्याला `base_reward * 1/1 == base_reward` मिळते. जर साक्षांकन पुढील स्लॉटमध्ये आले, तर साक्षांकित करणाऱ्याला `base_reward * 1/2` मिळते आणि असेच पुढे. + +ब्लॉक प्रस्तावक ब्लॉकमध्ये समाविष्ट **प्रत्येक वैध साक्षांकनासाठी** `8 / 64 * base_reward` प्राप्त करतात, त्यामुळे बक्षिसाचे वास्तविक मूल्य साक्षांकित करणाऱ्या व्हॅलिडेटर्सच्या संख्येनुसार स्केल होते. ब्लॉक प्रस्तावक त्यांच्या प्रस्तावित ब्लॉकमध्ये इतर व्हॅलिडेटर्सच्या गैरवर्तनाचा पुरावा समाविष्ट करून आपले बक्षीस वाढवू शकतात. ही बक्षिसे व्हॅलिडेटरच्या प्रामाणिकपणाला प्रोत्साहन देणारे “गाजर” आहेत. स्लॅशिंगचा समावेश करणाऱ्या ब्लॉक प्रस्तावकला `slashed_validators_effective_balance / 512` बक्षीस दिले जाईल. + +### दंड {#penalties} + +आतापर्यंत आपण उत्तम वर्तन करणाऱ्या व्हॅलिडेटर्सचा विचार केला आहे, पण जे व्हॅलिडेटर्स वेळेवर हेड, सोर्स आणि टार्गेट मते देत नाहीत किंवा हळू देतात त्यांचे काय? + +टार्गेट आणि सोर्स मते चुकवल्याबद्दलचा दंड, साक्षांकित करणाऱ्याने ते सादर केल्यास त्याला मिळणाऱ्या बक्षिसांच्या बरोबरीचा असतो. याचा अर्थ असा की त्यांच्या बॅलन्समध्ये बक्षीस जोडण्याऐवजी, त्यांच्या बॅलन्समधून समान मूल्य काढून टाकले जाते. हेड व्होट चुकवल्याबद्दल कोणताही दंड नाही (म्हणजे, हेड व्होट्सना फक्त बक्षीस दिले जाते, कधीही दंड आकारला जात नाही). `inclusion_delay` सोबत कोणताही दंड जोडलेला नाही - बक्षीस फक्त व्हॅलिडेटरच्या बॅलन्समध्ये जोडले जाणार नाही. ब्लॉक प्रस्तावित करण्यात अयशस्वी झाल्यास कोणताही दंड नाही. + +[कन्सेन्सस स्पेक्स](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md) मध्ये बक्षिसे आणि दंडांबद्दल अधिक वाचा. बेलॅट्रिक्स अपग्रेडमध्ये बक्षिसे आणि दंड समायोजित केले गेले - [Peep an EIP व्हिडिओ](https://www.youtube.com/watch?v=iaAEGs1DMgQ) मध्ये यावर डॅनी रायन आणि विटालिक यांची चर्चा पहा. + +## स्लॅशिंग {#slashing} + +स्लॅशिंग ही एक अधिक गंभीर कृती आहे ज्यामुळे एका व्हॅलिडेटरला नेटवर्कमधून जबरदस्तीने काढून टाकले जाते आणि त्यांच्या स्टेक केलेल्या ईथरचे संबंधित नुकसान होते. एका व्हॅलिडेटरला स्लॅश करण्याचे तीन मार्ग आहेत, जे सर्व म्हणजे ब्लॉक्सचे अप्रामाणिक प्रस्ताव किंवा साक्षांकन: + +- एकाच स्लॉटसाठी दोन वेगळे ब्लॉक्स प्रस्तावित करणे आणि त्यावर सही करणे +- एका ब्लॉकला साक्षांकित करून जो दुसऱ्या ब्लॉकला “सराउंड” करतो (प्रभावीपणे इतिहास बदलतो) +- एकाच ब्लॉकसाठी दोन उमेदवारांना साक्षांकित करून “डबल व्होटिंग” करणे + +जर या कृती शोधल्या गेल्या, तर व्हॅलिडेटरला स्लॅश केले जाते. याचा अर्थ असा की 32 ETH व्हॅलिडेटरसाठी 0.0078125 तात्काळ बर्न केले जाते (सक्रिय बॅलन्ससह रेषीय प्रमाणात), त्यानंतर 36 दिवसांचा काढण्याचा कालावधी सुरू होतो. या काढण्याच्या कालावधीत व्हॅलिडेटरचा स्टेक हळूहळू कमी होत जातो. मध्यभागी (18 व्या दिवशी) एक अतिरिक्त दंड लागू केला जातो, ज्याची तीव्रता स्लॅशिंग घटनेच्या 36 दिवस आधी सर्व स्लॅश केलेल्या व्हॅलिडेटर्सच्या एकूण स्टेक केलेल्या ईथरनुसार स्केल होते. याचा अर्थ असा की जेव्हा अधिक व्हॅलिडेटर्सना स्लॅश केले जाते, तेव्हा स्लॅशची तीव्रता वाढते. जास्तीत जास्त स्लॅश म्हणजे सर्व स्लॅश केलेल्या व्हॅलिडेटर्सचा पूर्ण प्रभावी बॅलन्स (म्हणजे, जर बरेच व्हॅलिडेटर्स स्लॅश होत असतील तर ते आपला संपूर्ण स्टेक गमावू शकतात). दुसरीकडे, एकच, वेगळी स्लॅशिंग घटना व्हॅलिडेटरच्या स्टेकचा फक्त एक लहान भाग बर्न करते. हा मध्यबिंदू दंड जो स्लॅश केलेल्या व्हॅलिडेटर्सच्या संख्येनुसार स्केल होतो, त्याला “कोरिलेशन पेनल्टी” म्हणतात. + +## निष्क्रियता गळती {#inactivity-leak} + +जर कन्सेन्सस लेअर चारपेक्षा जास्त इपॉक्ससाठी फायनलाइज झाले नाही, तर “निष्क्रियता गळती” नावाचा एक आपत्कालीन प्रोटोकॉल सक्रिय केला जातो. निष्क्रियता गळतीचे अंतिम उद्दिष्ट चेनला फायनलिटी परत मिळवण्यासाठी आवश्यक परिस्थिती निर्माण करणे आहे. वर स्पष्ट केल्याप्रमाणे, फायनलिटीसाठी एकूण स्टेक केलेल्या ईथरपैकी 2/3 बहुमताची सोर्स आणि टार्गेट चेकपॉइंट्सवर सहमत होण्याची आवश्यकता असते. जर एकूण व्हॅलिडेटर्सपैकी 1/3 पेक्षा जास्त व्हॅलिडेटर्स ऑफलाइन गेले किंवा योग्य साक्षांकन सादर करण्यात अयशस्वी झाले, तर 2/3 सुपरमेजोरिटीसाठी चेकपॉइंट्स फायनलाइज करणे शक्य नसते. निष्क्रियता गळतीमुळे निष्क्रिय व्हॅलिडेटर्सचा स्टेक हळूहळू कमी होत जातो जोपर्यंत ते एकूण स्टेकच्या 1/3 पेक्षा कमी नियंत्रित करत नाहीत, ज्यामुळे उर्वरित सक्रिय व्हॅलिडेटर्स चेन फायनलाइज करू शकतात. निष्क्रिय व्हॅलिडेटर्सचा पूल कितीही मोठा असला तरी, उर्वरित सक्रिय व्हॅलिडेटर्स अखेरीस >2/3 स्टेक नियंत्रित करतील. स्टेकचे नुकसान हे निष्क्रिय व्हॅलिडेटर्सना शक्य तितक्या लवकर पुन्हा सक्रिय होण्यासाठी एक मजबूत प्रोत्साहन आहे! मेडाला टेस्टनेटवर निष्क्रियता गळतीची परिस्थिती आली होती, जेव्हा < 66% सक्रिय व्हॅलिडेटर्स ब्लॉकचेनच्या सध्याच्या हेडवर सहमतीवर येऊ शकले नव्हते. निष्क्रियता गळती सक्रिय झाली आणि अखेरीस फायनलिटी पुन्हा मिळवली गेली! + +कन्सेन्सस मेकॅनिझमची बक्षीस, दंड आणि स्लॅशिंगची रचना वैयक्तिक व्हॅलिडेटर्सना योग्यरित्या वागण्यासाठी प्रोत्साहित करते. तथापि, या डिझाइन निवडींमधून एक अशी प्रणाली उदयास येते जी अनेक क्लायंट्समध्ये व्हॅलिडेटर्सच्या समान वितरणाला जोरदारपणे प्रोत्साहित करते, आणि एकल-क्लायंट वर्चस्वाला जोरदारपणे परावृत्त करते. + +## पुढील वाचन {#further-reading} + +- [Ethereum अपग्रेड करणे: प्रोत्साहन लेअर](https://eth2book.info/altair/part2/incentives) +- [Ethereum च्या हायब्रीड कॅस्पर प्रोटोकॉलमधील प्रोत्साहन](https://arxiv.org/pdf/1903.04205.pdf) +- [विटालिकचे भाष्य केलेले स्पेक](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2 स्लॅशिंग प्रतिबंधक टिप्स](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251 अंतर्गत स्लॅशिंग दंडांचे विश्लेषण](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_स्रोत_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..9ac910dcea7 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "अशक्त व्यक्तिनिष्ठता" +description: "अशक्त व्यक्तिनिष्ठता आणि PoS Ethereum मधील तिच्या भूमिकेचे स्पष्टीकरण." +lang: mr +--- + +ब्लॉकचेनमध्ये व्यक्तिनिष्ठता म्हणजे सद्य स्थितीवर सहमत होण्यासाठी सामाजिक माहितीवर अवलंबून राहणे. नेटवर्कवरील इतर पिअर्सकडून गोळा केलेल्या माहितीनुसार निवडले जाणारे अनेक वैध फोर्क असू शकतात. याउलट वस्तुनिष्ठता आहे, जी अशा चेन्सना संदर्भित करते जिथे फक्त एकच संभाव्य वैध चेन असते ज्यावर सर्व नोड्स त्यांचे कोडेड नियम लागू करून सहमत होतील. तिसरी स्थिती देखील आहे, जी अशक्त व्यक्तिनिष्ठता म्हणून ओळखली जाते. हे अशा चेनला संदर्भित करते जी सामाजिकरित्या काही सुरुवातीची माहिती प्राप्त झाल्यानंतर वस्तुनिष्ठपणे प्रगती करू शकते. + +## पूर्वतयारी {#prerequisites} + +हे पान समजून घेण्यासाठी, प्रथम [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) च्या मूलभूत गोष्टी समजून घेणे आवश्यक आहे. + +## अशक्त व्यक्तिनिष्ठता कोणत्या समस्या सोडवते? {#problems-ws-solves} + +प्रूफ-ऑफ-स्टेक ब्लॉकचेनमध्ये व्यक्तिनिष्ठता अंतर्भूत आहे कारण अनेक फोर्कमधून योग्य चेन निवडणे हे ऐतिहासिक मतांची मोजणी करून केले जाते. हे ब्लॉकचेनला अनेक हल्ल्यांच्या मार्गांवर आणते, ज्यात लांब पल्ल्याच्या हल्ल्यांचा समावेश आहे, ज्यामध्ये चेनमध्ये खूप लवकर सहभागी झालेले नोड्स एक पर्यायी फोर्क तयार करतात जो ते नंतर स्वतःच्या फायद्यासाठी रिलीज करतात. वैकल्पिकरित्या, जर 33% व्हॅलिडेटर्सनी त्यांचा स्टेक काढून घेतला पण तरीही साक्षांकन आणि ब्लॉक्स तयार करणे सुरू ठेवले, तर ते एक पर्यायी फोर्क तयार करू शकतात जो कॅनॉनिकल चेनशी संघर्ष करतो. नवीन नोड्स किंवा जे नोड्स बऱ्याच काळापासून ऑफलाइन आहेत, त्यांना हे माहीत नसेल की या आक्रमण करणाऱ्या व्हॅलिडेटर्सनी त्यांचे फंड काढून घेतले आहेत, त्यामुळे आक्रमणकर्ते त्यांना चुकीच्या चेनचे अनुसरण करण्यास फसवू शकतात. Ethereum या हल्ल्यांचे मार्ग सोडवू शकते, ते अशा मर्यादा घालून जे यंत्रणेच्या व्यक्तिनिष्ठ पैलूंना—आणि त्यामुळे विश्वासाच्या गृहितकांना—किमान पातळीवर कमी करतात. + +## अशक्त व्यक्तिनिष्ठता चेकपॉईंट्स {#ws-checkpoints} + +प्रूफ-ऑफ-स्टेक Ethereum मध्ये "अशक्त व्यक्तिनिष्ठता चेकपॉईंट्स" वापरून अशक्त व्यक्तिनिष्ठता लागू केली जाते. हे स्टेट रूट्स आहेत ज्यावर नेटवर्कवरील सर्व नोड्स सहमत आहेत की ते कॅनॉनिकल चेनमध्ये आहेत. ते जेनेसिस ब्लॉक्स सारखेच "सार्वत्रिक सत्य" उद्दिष्ट पूर्ण करतात, फक्त ते ब्लॉकचेनमध्ये जेनेसिस स्थितीत नसतात. फोर्क निवड अल्गोरिदम विश्वास ठेवतो की त्या चेकपॉईंटमध्ये परिभाषित ब्लॉकचेन स्थिती योग्य आहे आणि ते त्या बिंदूपासून पुढे चेन स्वतंत्रपणे आणि वस्तुनिष्ठपणे सत्यापित करते. चेकपॉईंट्स "रिव्हर्ट मर्यादा" म्हणून काम करतात कारण अशक्त-व्यक्तिनिष्ठता चेकपॉईंट्सच्या आधी असलेले ब्लॉक्स बदलले जाऊ शकत नाहीत. हे लांब पल्ल्याचे हल्ले कमी करते, कारण या यंत्रणेच्या डिझाइनचा भाग म्हणून लांब पल्ल्याच्या फोर्कला अवैध म्हणून परिभाषित केले जाते. अशक्त व्यक्तिनिष्ठता चेकपॉईंट्स व्हॅलिडेटर पैसे काढण्याच्या कालावधीपेक्षा कमी अंतराने विभक्त आहेत याची खात्री केल्याने हे निश्चित होते की चेन फोर्क करणार्‍या व्हॅलिडेटरला त्यांचा स्टेक काढण्यापूर्वी किमान काही मर्यादित रक्कम स्लॅश केली जाते आणि नवीन प्रवेशकर्त्यांना ज्या व्हॅलिडेटर्सनी स्टेक काढला आहे त्यांच्याकडून चुकीच्या फोर्कमध्ये फसवले जाऊ शकत नाही. + +## अशक्त व्यक्तिनिष्ठता चेकपॉईंट्स आणि अंतिम ब्लॉक्समधील फरक {#difference-between-ws-and-finalized-blocks} + +अंतिम ब्लॉक्स आणि अशक्त व्यक्तिनिष्ठता चेकपॉईंट्सना Ethereum नोड्सकडून वेगळी वागणूक दिली जाते. जर एखाद्या नोडला दोन प्रतिस्पर्धी अंतिम ब्लॉक्सबद्दल माहिती झाली, तर तो त्या दोन्हींमध्ये विभागला जातो - कॅनॉनिकल फोर्क कोणता आहे हे स्वयंचलितपणे ओळखण्याचा त्याच्याकडे कोणताही मार्ग नसतो. हे कन्सेंसस अयशस्वी झाल्याचे लक्षण आहे. याउलट, नोड त्याच्या अशक्त व्यक्तिनिष्ठता चेकपॉईंटशी संघर्ष करणारा कोणताही ब्लॉक नाकारतो. नोडच्या दृष्टिकोनातून, अशक्त व्यक्तिनिष्ठता चेकपॉईंट एक परिपूर्ण सत्य दर्शवते जे त्याच्या पिअर्सकडून मिळालेल्या नवीन ज्ञानाने कमी केले जाऊ शकत नाही. + +## किती अशक्त? {#how-weak-is-weak} + +Ethereum च्या प्रूफ-ऑफ-स्टेकचा व्यक्तिनिष्ठ पैलू म्हणजे सिंक करण्यासाठी विश्वसनीय स्त्रोताकडून अलीकडील स्थितीची (अशक्त व्यक्तिनिष्ठता चेकपॉईंट) आवश्यकता. खराब अशक्त व्यक्तिनिष्ठता चेकपॉईंट मिळण्याचा धोका खूप कमी आहे कारण ते ब्लॉक एक्सप्लोरर किंवा अनेक नोड्ससारख्या अनेक स्वतंत्र सार्वजनिक स्त्रोतांवर तपासले जाऊ शकतात. तथापि, कोणतेही सॉफ्टवेअर ॲप्लिकेशन चालवण्यासाठी नेहमीच काही प्रमाणात विश्वासाची आवश्यकता असते, उदाहरणार्थ, सॉफ्टवेअर डेव्हलपर्सनी प्रामाणिक सॉफ्टवेअर तयार केले आहे यावर विश्वास ठेवणे. + +एक अशक्त व्यक्तिनिष्ठता चेकपॉईंट क्लायंट सॉफ्टवेअरचा भाग म्हणून देखील येऊ शकतो. वादग्रस्तपणे, एक आक्रमणकर्ता सॉफ्टवेअरमधील चेकपॉईंटमध्ये फेरफार करू शकतो आणि तितक्याच सहजपणे सॉफ्टवेअरमध्येच फेरफार करू शकतो. या समस्येवर कोणताही खरा क्रिप्टो-इकॉनॉमिक मार्ग नाही, परंतु Ethereum मध्ये अविश्वसनीय डेव्हलपर्सचा प्रभाव कमी केला जातो कारण त्यात अनेक स्वतंत्र क्लायंट टीम्स आहेत, प्रत्येक टीम वेगवेगळ्या भाषांमध्ये समकक्ष सॉफ्टवेअर तयार करत आहे, आणि सर्वांचा एक प्रामाणिक चेन राखण्यात रस आहे. ब्लॉक एक्सप्लोरर अशक्त व्यक्तिनिष्ठता चेकपॉईंट्स किंवा इतर कोठूनतरी मिळवलेले चेकपॉईंट्स एका अतिरिक्त स्त्रोतासह क्रॉस-रेफरन्स करण्याचा मार्ग देखील प्रदान करू शकतात. + +शेवटी, चेकपॉईंट्स इतर नोड्सकडून मागवले जाऊ शकतात; कदाचित दुसरा Ethereum वापरकर्ता जो पूर्ण नोड चालवतो, तो एक चेकपॉईंट प्रदान करू शकतो जो व्हॅलिडेटर्स नंतर ब्लॉक एक्सप्लोररच्या डेटासह सत्यापित करू शकतात. एकंदरीत, अशक्त व्यक्तिनिष्ठता चेकपॉईंटच्या प्रदात्यावर विश्वास ठेवणे हे क्लायंट डेव्हलपर्सवर विश्वास ठेवण्याइतकेच समस्याप्रधान मानले जाऊ शकते. एकूण आवश्यक विश्वास कमी आहे. हे लक्षात घेणे महत्त्वाचे आहे की हे विचार केवळ अशा अत्यंत अशक्य घटनेत महत्त्वाचे ठरतात, जेव्हा बहुसंख्य व्हॅलिडेटर्स ब्लॉकचेनचा पर्यायी फोर्क तयार करण्याचा कट रचतात. इतर कोणत्याही परिस्थितीत, निवडण्यासाठी फक्त एकच Ethereum चेन असते. + +## अधिक वाचन {#further-reading} + +- [Eth2 मध्ये अशक्त व्यक्तिनिष्ठता](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [विटालिक: मी अशक्त व्यक्तिनिष्ठतेवर प्रेम करायला कसे शिकलो](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [अशक्त व्यक्तिनिष्ठता (Teku डॉक्स)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [फेज-0 अशक्त व्यक्तिनिष्ठता मार्गदर्शक](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [Ethereum 2.0 मधील अशक्त व्यक्तिनिष्ठतेचे विश्लेषण](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..838f2617aff --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "विथड्रॉवल क्रेडेन्शियल्स" +description: "व्हॅलिडेटर विथड्रॉवल क्रेडेंशियलच्या प्रकारांचे (0x00, 0x01, 0x02) स्पष्टीकरण आणि Ethereum स्टेकर्सवर होणारे त्यांचे परिणाम." +lang: mr +--- + +प्रत्येक व्हॅलिडेटरकडे एक **विथड्रॉवल क्रेडेंशियल** असते, जे ठरवते की त्यांचे स्टेक केलेले ETH आणि रिवॉर्ड्स कसे आणि कोठून काढले जाऊ शकतात. क्रेडेंशियलचा प्रकार पहिल्या बाइटद्वारे दर्शविला जातो: `0x00`, `0x01`, किंवा `0x02`. त्यांचे स्टेक व्यवस्थापित करणाऱ्या व्हॅलिडेटर्ससाठी हे प्रकार समजून घेणे महत्त्वाचे आहे. + +## 0x00: Shapella-पूर्व क्रेडेंशियल्स {#0x00-credentials} + +`0x00` प्रकार हा Shapella अपग्रेडच्या (एप्रिल २०२३) आधीचा मूळ विथड्रॉवल क्रेडेंशियल फॉरमॅट आहे. या प्रकारच्या क्रेडेंशियल असलेल्या व्हॅलिडेटर्सचा कोणताही एक्झिक्यूशन लेयर विथड्रॉवल ॲड्रेस सेट केलेला नसतो, याचा अर्थ त्यांचे फंड्स कन्सेन्सस लेयरवर लॉक राहतात. जर तुमच्याकडे अजूनही `0x00` क्रेडेंशियल्स असतील, तर तुम्हाला कोणतेही विथड्रॉवल मिळवण्यापूर्वी `0x01` किंवा `0x02` मध्ये अपग्रेड करणे आवश्यक आहे. + +## 0x01: लेगसी विथड्रॉवल क्रेडेंशियल्स {#0x01-credentials} + +`0x01` प्रकार Shapella अपग्रेडसोबत सादर करण्यात आला आणि ज्या व्हॅलिडेटर्सना एक्झिक्यूशन लेयर विथड्रॉवल ॲड्रेस सेट करायचा होता त्यांच्यासाठी हे मानक बनले. `0x01` क्रेडेंशियल्ससह: + +- 32 ETH पेक्षा जास्त असलेली कोणतीही शिल्लक तुमच्या विथड्रॉवल ॲड्रेसवर **आपोआप पाठवली जाते** +- पूर्ण एक्झिट मानक एक्झिट रांगेतून जातात +- 32 ETH पेक्षा जास्त रिवॉर्ड्स कंपाऊंड होऊ शकत नाहीत—ते नियमितपणे काढले जातात + +**काही व्हॅलिडेटर्स अजूनही 0x01 का वापरतात:** हे सोपे आणि परिचित आहे. अनेक व्हॅलिडेटर्सनी Shapella नंतर डिपॉझिट केले आहे आणि त्यांच्याकडे आधीपासूनच हा प्रकार आहे, आणि ज्यांना अतिरिक्त शिलकीचे आपोआप विथड्रॉवल हवे आहे त्यांच्यासाठी ते ठीक काम करते. + +**याची शिफारस का केली जात नाही:** `0x01` सह, तुम्ही 32 ETH पेक्षा जास्त रिवॉर्ड्स कंपाऊंड करण्याची क्षमता गमावता. प्रत्येक अतिरिक्त भाग आपोआप काढला जातो, ज्यामुळे तुमच्या व्हॅलिडेटरची कमाईची क्षमता मर्यादित होते आणि काढलेल्या फंड्सचे स्वतंत्रपणे व्यवस्थापन करणे आवश्यक ठरते. + +## 0x02: कंपाऊंडिंग विथड्रॉवल क्रेडेंशियल्स {#0x02-credentials} + +`0x02` प्रकार Pectra अपग्रेडसोबत सादर करण्यात आला आणि आज व्हॅलिडेटर्ससाठी हा **शिफारस केलेला पर्याय** आहे. `0x02` क्रेडेंशियल्स असलेल्या व्हॅलिडेटर्सना कधीकधी "कंपाऊंडिंग व्हॅलिडेटर्स" म्हटले जाते. + +`0x02` क्रेडेंशियल्ससह: + +- 32 ETH पेक्षा जास्त रिवॉर्ड्स 2048 ETH च्या कमाल प्रभावी शिलकीपर्यंत 1 ETH च्या वाढीमध्ये **कंपाऊंड** होतात. +- आंशिक विथड्रॉवलची मॅन्युअली विनंती करणे आवश्यक आहे (2048 ETH च्या मर्यादेपेक्षा जास्त झाल्यावरच आपोआप स्वीप्स होतात) +- व्हॅलिडेटर्स अनेक 32 ETH व्हॅलिडेटर्सना एकाच उच्च-शिलकीच्या व्हॅलिडेटरमध्ये एकत्रित करू शकतात. +- पूर्ण एक्झिट अजूनही मानक एक्झिट रांगेद्वारे समर्थित आहेत + +आंशिक विथड्रॉवल आणि एकत्रीकरण दोन्ही [Launchpad Validator Actions](https://launchpad.ethereum.org/en/validator-actions) द्वारे केले जाऊ शकतात. + +**व्हॅलिडेटर्सनी 0x02 ला प्राधान्य का द्यावे:** हे कंपाऊंडिंगद्वारे उत्तम भांडवली कार्यक्षमता प्रदान करते, विथड्रॉवल कधी होतात यावर अधिक नियंत्रण देते आणि व्हॅलिडेटर एकत्रीकरणास समर्थन देते. जे सोलो स्टेकर्स कालांतराने रिवॉर्ड्स जमा करतात, त्यांच्यासाठी याचा अर्थ असा की त्यांची प्रभावी शिल्लक—आणि त्यामुळे त्यांचे रिवॉर्ड्स—मॅन्युअल हस्तक्षेपाशिवाय 32 ETH च्या पुढे वाढू शकतात. + +**महत्त्वाचे:** एकदा तुम्ही `0x01` मधून `0x02` मध्ये रूपांतरित केल्यावर, तुम्ही परत येऊ शकत नाही. + +टाइप 2 क्रेडेंशियल्समध्ये रूपांतरित करण्याच्या आणि MaxEB वैशिष्ट्याच्या तपशीलवार मार्गदर्शकासाठी, [MaxEB स्पष्टीकरण पृष्ठ](/roadmap/pectra/maxeb/) पहा. + +## मी काय निवडावे? {#what-should-i-pick} + +- **नवीन व्हॅलिडेटर्स:** `0x02` निवडा. हे उत्तम कंपाऊंडिंग आणि लवचिकतेसह आधुनिक मानक आहे. +- **विद्यमान 0x01 व्हॅलिडेटर्स:** जर तुम्हाला 32 ETH पेक्षा जास्त रिवॉर्ड्स कंपाऊंड करायचे असतील किंवा व्हॅलिडेटर्स एकत्रित करण्याची योजना असेल तर `0x02` मध्ये रूपांतरित करण्याचा विचार करा. +- **विद्यमान 0x00 व्हॅलिडेटर्स:** त्वरित अपग्रेड करा—तुम्ही तुमचे क्रेडेंशियल्स अद्ययावत केल्याशिवाय विथड्रॉ करू शकत नाही. तुम्हाला आधी `0x01` मध्ये रूपांतरित करावे लागेल, मग तुम्ही `0x02` मध्ये रूपांतरित करू शकता. + +## विथड्रॉवल क्रेडेंशियल्स व्यवस्थापित करण्यासाठी टूल्स {#withdrawal-credential-tools} + +क्रेडेंशियल प्रकारांमध्ये निवड करण्यासाठी किंवा रूपांतरित करण्यासाठी अनेक टूल्स समर्थन देतात: + +- **[Ethereum Staking Launchpad](https://launchpad.ethereum.org/en/validator-actions)** - डिपॉझिट आणि व्हॅलिडेटर व्यवस्थापनासाठी अधिकृत टूल, ज्यामध्ये क्रेडेंशियल रूपांतरण आणि एकत्रीकरण समाविष्ट आहे. +- **[Pectra Staking Manager](https://pectrastaking.com)** - रूपांतरण आणि एकत्रीकरणासाठी वॉलेट-कनेक्ट समर्थनासह वेब UI +- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** - बॅच रूपांतरणासाठी कमांड-लाइन टूल +- **[Ethereal](https://github.com/wealdtech/ethereal)** - Ethereum ऑपरेशन्ससाठी CLI टूल, व्हॅलिडेटर व्यवस्थापनासह + +एकत्रीकरण टूल्सची संपूर्ण यादी आणि तपशीलवार रूपांतरण सूचनांसाठी, [MaxEB एकत्रीकरण टूलिंग](/roadmap/pectra/maxeb/#consolidation-tooling) पहा. + +## पुढील वाचन {#further-reading} + +- [प्रूफ-ऑफ-स्टेक Ethereum मधील कीज](/developers/docs/consensus-mechanisms/pos/keys/) - व्हॅलिडेटर कीज आणि त्या विथड्रॉवल क्रेडेंशियल्सशी कशा संबंधित आहेत याबद्दल जाणून घ्या. +- [MaxEB](/roadmap/pectra/maxeb/) - Pectra अपग्रेड आणि कमाल प्रभावी शिल्लक वैशिष्ट्यावर तपशीलवार मार्गदर्शक. diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..8ce57c7098d --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "प्रूफ-ऑफ-वर्क (PoW)" +description: "प्रूफ-ऑफ-वर्क एकमत प्रोटोकॉलचे स्पष्टीकरण आणि Ethereum मधील त्याची भूमिका." +lang: mr +--- + +Ethereum नेटवर्कने **[प्रूफ-ऑफ-वर्क (PoW)](/developers/docs/consensus-mechanisms/pow)** समाविष्ट असलेल्या एकमत यंत्रणेचा वापर करून सुरुवात केली. यामुळे Ethereum नेटवर्कच्या नोड्सना Ethereum ब्लॉकचेनवर रेकॉर्ड केलेल्या सर्व माहितीच्या स्थितीवर सहमत होण्यास आणि विशिष्ट प्रकारचे आर्थिक हल्ले रोखण्यास मदत झाली. तथापि, Ethereum ने 2022 मध्ये प्रूफ-ऑफ-वर्क बंद केले आणि त्याऐवजी [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos) वापरण्यास सुरुवात केली. + + + + + + प्रूफ-ऑफ-वर्क आता नापसंत झाले आहे. Ethereum आता त्याच्या एकमत यंत्रणेचा भाग म्हणून प्रूफ-ऑफ-वर्क वापरत नाही. त्याऐवजी, ते प्रूफ-ऑफ-स्टेक वापरते. [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) आणि [स्टेकिंग](/staking/) वर अधिक वाचा. + + + + +## पूर्वतयारी {#prerequisites} + +हे पान अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [transactions](/developers/docs/transactions/), [blocks](/developers/docs/blocks/), आणि [consensus mechanisms](/developers/docs/consensus-mechanisms/) बद्दल वाचा. + +## प्रूफ-ऑफ-वर्क (PoW) म्हणजे काय? {#what-is-pow} + +नाकामोटो एकमत, जे प्रूफ-ऑफ-वर्कचा उपयोग करते, ही ती यंत्रणा आहे जिने एकेकाळी विकेंद्रित Ethereum नेटवर्कला खाते शिल्लक आणि व्यवहारांचा क्रम यासारख्या गोष्टींवर एकमतापर्यंत पोहोचण्याची (म्हणजे, सर्व नोड्स सहमत) परवानगी दिली. यामुळे वापरकर्त्यांना त्यांचे कॉइन्स "डबल स्पेंड" करण्यापासून रोखले गेले आणि Ethereum चेनवर हल्ला करणे किंवा त्यात फेरफार करणे खूप कठीण होईल हे सुनिश्चित केले गेले. हे सुरक्षा गुणधर्म आता [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) म्हणून ओळखल्या जाणार्‍या एकमत यंत्रणेचा वापर करून प्रूफ-ऑफ-स्टेककडून येतात. + +## प्रूफ-ऑफ-वर्क आणि मायनिंग {#pow-and-mining} + +प्रूफ-ऑफ-वर्क हा मूळ अल्गोरिदम आहे जो प्रूफ-ऑफ-वर्क ब्लॉकचेनवर मायनर्स करत असलेल्या कामासाठी अडचण आणि नियम सेट करतो. मायनिंग हेच खरे "काम" आहे. चेनमध्ये वैध ब्लॉक्स जोडण्याची ही क्रिया आहे. हे महत्त्वाचे आहे कारण चेनची लांबी नेटवर्कला ब्लॉकचेनच्या योग्य फोर्कचे अनुसरण करण्यास मदत करते. जितके जास्त "काम" केले जाईल, तितकी चेन लांब होईल आणि ब्लॉक क्रमांक जितका जास्त असेल, तितके नेटवर्क सद्यस्थितीबद्दल अधिक निश्चित होऊ शकते. + +[मायनिंगवर अधिक](/developers/docs/consensus-mechanisms/pow/mining/) + +## Ethereum चे प्रूफ-ऑफ-वर्क कसे काम करत होते? {#how-it-works} + +Ethereum व्यवहारांवर ब्लॉक्समध्ये प्रक्रिया केली जाते. आता नापसंत झालेल्या प्रूफ-ऑफ-वर्क Ethereum मध्ये, प्रत्येक ब्लॉकमध्ये हे समाविष्ट होते: + +- ब्लॉकची अडचण – उदाहरणार्थ: 3,324,092,183,262,715 +- मिक्सहॅश – उदाहरणार्थ: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- नॉन्स – उदाहरणार्थ: `0xd3ee432b4fb3d26b` + +हा ब्लॉक डेटा थेट प्रूफ-ऑफ-वर्कशी संबंधित होता. + +### प्रूफ-ऑफ-वर्क मधील काम {#the-work} + +प्रूफ-ऑफ-वर्क प्रोटोकॉल, Ethash, नुसार मायनर्सना ब्लॉकसाठी नॉन्स शोधण्याकरिता प्रयत्न आणि त्रुटीच्या तीव्र शर्यतीतून जावे लागत होते. केवळ वैध नॉन्स असलेले ब्लॉक्स चेनमध्ये जोडले जाऊ शकत होते. + +ब्लॉक तयार करण्याच्या शर्यतीत असताना, एक मायनर वारंवार एका डेटासेटला (जो केवळ संपूर्ण चेन डाउनलोड करून आणि चालवून मिळवता येतो, जसे एक मायनर करतो) गणितीय फंक्शनमधून चालवत असे. डेटासेटचा वापर ब्लॉकच्या अडचणीनुसार ठरवलेल्या लक्ष्यापेक्षा कमी असलेला मिक्सहॅश निर्माण करण्यासाठी केला जात असे. हे करण्याचा सर्वोत्तम मार्ग म्हणजे प्रयत्न आणि त्रुटी. + +अडचणीमुळे हॅशसाठी लक्ष्य निर्धारित केले जात असे. लक्ष्य जितके कमी, वैध हॅशचा संच तितकाच लहान. एकदा तयार झाल्यावर, इतर मायनर्स आणि क्लायंट्ससाठी याची पडताळणी करणे खूप सोपे होते. जरी एक व्यवहार बदलला तरी, हॅश पूर्णपणे वेगळा होईल, जो फसवणुकीचा संकेत देतो. + +हॅशिंगमुळे फसवणूक शोधणे सोपे होते. पण एक प्रक्रिया म्हणून प्रूफ-ऑफ-वर्क चेनवर हल्ला करण्यापासून एक मोठा प्रतिबंधक देखील होता. + +### प्रूफ-ऑफ-वर्क आणि सुरक्षा {#security} + +मुख्य Ethereum चेनवर हे काम करण्यासाठी मायनर्सना प्रोत्साहन दिले जात असे. मायनर्सच्या उपसमूहाला त्यांची स्वतःची चेन सुरू करण्यासाठी फार कमी प्रोत्साहन होते—कारण ते प्रणालीला कमकुवत करते. ब्लॉकचेन सत्याचा स्रोत म्हणून एकाच स्थितीवर अवलंबून असतात. + +प्रूफ-ऑफ-वर्कचा उद्देश चेन वाढवणे हा होता. सर्वात लांब चेन वैध म्हणून सर्वात विश्वासार्ह होती कारण ती निर्माण करण्यासाठी सर्वात जास्त संगणकीय काम केले गेले होते. Ethereum च्या PoW प्रणालीमध्ये, व्यवहार मिटवणारे, बनावट व्यवहार करणारे नवीन ब्लॉक्स तयार करणे किंवा दुसरी चेन राखणे जवळजवळ अशक्य होते. कारण एका दुर्भावनापूर्ण मायनरला नेहमीच ब्लॉक नॉन्स इतर सर्वांपेक्षा वेगाने सोडवावे लागले असते. + +सातत्याने दुर्भावनापूर्ण तरीही वैध ब्लॉक्स तयार करण्यासाठी, एका दुर्भावनापूर्ण मायनरला इतर सर्वांना हरवण्यासाठी नेटवर्कच्या ५१% पेक्षा जास्त मायनिंग शक्तीची गरज भासली असती. त्या प्रमाणात "काम" करण्यासाठी खूप महाग संगणकीय शक्तीची आवश्यकता असते आणि खर्च झालेली ऊर्जा हल्ल्यात मिळालेल्या फायद्यांपेक्षा जास्त असू शकते. + +### प्रूफ-ऑफ-वर्क अर्थशास्त्र {#economics} + +प्रूफ-ऑफ-वर्क प्रणालीमध्ये नवीन चलन जारी करण्यासाठी आणि मायनर्सना काम करण्यासाठी प्रोत्साहन देण्यासाठी देखील जबाबदार होते. + +[कॉन्स्टँटिनोपल अपग्रेड](/ethereum-forks/#constantinople) पासून, यशस्वीरित्या ब्लॉक तयार करणाऱ्या मायनर्सना दोन नव्याने तयार केलेले ETH आणि व्यवहार शुल्काचा काही भाग बक्षीस म्हणून मिळत असे. ओमर ब्लॉक्सना देखील 1.75 ETH भरपाई मिळत असे. ओमर ब्लॉक्स हे वैध ब्लॉक्स होते जे एका मायनरने त्याच वेळी तयार केले होते ज्यावेळी दुसऱ्या मायनरने कॅनोनिकल ब्लॉक तयार केला, जे शेवटी कोणत्या चेनवर प्रथम बांधकाम झाले यावरून ठरवले गेले. ओमर ब्लॉक्स सहसा नेटवर्क लेटन्सीमुळे घडत. + +## अंतिमता {#finality} + +जेव्हा एखादा व्यवहार अशा ब्लॉकचा भाग असतो जो बदलू शकत नाही, तेव्हा त्याला Ethereum वर "अंतिमता" प्राप्त होते. + +कारण मायनर्स विकेंद्रित पद्धतीने काम करत होते, त्यामुळे एकाच वेळी दोन वैध ब्लॉक्स माइन केले जाऊ शकत होते. यामुळे एक तात्पुरता फोर्क तयार होतो. अखेरीस, यापैकी एक चेन नंतरचे ब्लॉक्स माइन करून त्यात जोडल्यानंतर आणि ती लांब झाल्यानंतर स्वीकृत चेन बनली. + +गोष्टी अधिक गुंतागुंतीच्या करण्यासाठी, तात्पुरत्या फोर्कवर नाकारलेले व्यवहार कदाचित स्वीकृत चेनमध्ये समाविष्ट केले गेले नसतील. याचा अर्थ ते उलटले जाऊ शकते. म्हणून अंतिमता म्हणजे व्यवहार अपरिवर्तनीय मानण्यापूर्वी तुम्ही प्रतीक्षा करावी लागणारी वेळ. पूर्वीच्या प्रूफ-ऑफ-वर्क Ethereum अंतर्गत, विशिष्ट ब्लॉक `N` वर जितके अधिक ब्लॉक्स माइन केले जातील, तितका `N` मधील व्यवहार यशस्वी झाल्याचा आणि ते उलटवले जाणार नाहीत याचा आत्मविश्वास जास्त असे. आता, प्रूफ-ऑफ-स्टेकसह, अंतिम स्वरूप देणे हे ब्लॉकचे संभाव्यतेऐवजी एक स्पष्ट गुणधर्म आहे. + +## प्रूफ-ऑफ-वर्क ऊर्जा-वापर {#energy} + +नेटवर्क सुरक्षित ठेवण्यासाठी आवश्यक असलेल्या ऊर्जेचे प्रमाण ही प्रूफ-ऑफ-वर्कवरील एक मोठी टीका आहे. सुरक्षा आणि विकेंद्रीकरण टिकवून ठेवण्यासाठी, प्रूफ-ऑफ-वर्कवरील Ethereum मोठ्या प्रमाणात ऊर्जा वापरत असे. प्रूफ-ऑफ-स्टेकवर स्विच करण्याच्या काही काळ आधी, Ethereum मायनर्स एकत्रितपणे सुमारे 70 TWh/वर्ष ऊर्जा वापरत होते (18-जुलै-2022 रोजी [digiconomist](https://digiconomist.net/) नुसार, हे चेक प्रजासत्ताकच्या वापराइतके आहे). + +## फायदे आणि तोटे {#pros-and-cons} + +| फायदे | बाधक | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| प्रूफ-ऑफ-वर्क तटस्थ आहे. सुरुवात करण्यासाठी तुम्हाला ETH ची गरज नाही आणि ब्लॉक रिवॉर्ड्स तुम्हाला 0ETH पासून सकारात्मक शिलकीपर्यंत जाण्याची परवानगी देतात. [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) मध्ये तुम्हाला सुरुवात करण्यासाठी ETH ची गरज आहे. | प्रूफ-ऑफ-वर्क इतकी ऊर्जा वापरते की ते पर्यावरणासाठी वाईट आहे. | +| प्रूफ-ऑफ-वर्क ही एक प्रयत्न केलेली आणि चाचणी केलेली एकमत यंत्रणा आहे जिने Bitcoin आणि Ethereum ला अनेक वर्षे सुरक्षित आणि विकेंद्रित ठेवले आहे. | तुम्हाला माइनिंग करायचे असल्यास, तुम्हाला अशा विशेष उपकरणांची आवश्यकता आहे की सुरुवात करण्यासाठी ही एक मोठी गुंतवणूक ठरते. | +| प्रूफ-ऑफ-स्टेकच्या तुलनेत ते अंमलात आणणे तुलनेने सोपे आहे. | वाढत्या संगणकीय आवश्यकतेमुळे, मायनिंग पूल्स संभाव्यतः मायनिंग गेमवर वर्चस्व गाजवू शकतात, ज्यामुळे केंद्रीकरण आणि सुरक्षेचे धोके निर्माण होतात. | + +## प्रूफ-ऑफ-स्टेकच्या तुलनेत {#compared-to-pos} + +उच्च स्तरावर, प्रूफ-ऑफ-स्टेकचे अंतिम ध्येय प्रूफ-ऑफ-वर्क सारखेच आहे: विकेंद्रित नेटवर्कला सुरक्षितपणे एकमतापर्यंत पोहोचण्यास मदत करणे. परंतु प्रक्रिया आणि कर्मचार्‍यांमध्ये काही फरक आहेत: + +- प्रूफ-ऑफ-स्टेक संगणकीय शक्तीचे महत्त्व स्टेक केलेल्या ETH ने बदलते. +- प्रूफ-ऑफ-स्टेक मायनर्सची जागा व्हॅलिडेटर्स घेतात. व्हॅलिडेटर्स नवीन ब्लॉक्स तयार करण्याची क्षमता सक्रिय करण्यासाठी त्यांचे ETH स्टेक करतात. +- व्हॅलिडेटर्स ब्लॉक्स तयार करण्यासाठी स्पर्धा करत नाहीत, त्याऐवजी त्यांना एका अल्गोरिदमद्वारे यादृच्छिकपणे निवडले जाते. +- अंतिमता अधिक स्पष्ट आहे: विशिष्ट चेकपॉइंट्सवर, जर 2/3 व्हॅलिडेटर्स ब्लॉकच्या स्थितीवर सहमत असतील तर तो अंतिम मानला जातो. व्हॅलिडेटर्सना यावर त्यांचे संपूर्ण स्टेक लावावे लागते, त्यामुळे जर त्यांनी नंतर संगनमत करण्याचा प्रयत्न केला, तर ते त्यांचे संपूर्ण स्टेक गमावतील. + +[प्रूफ-ऑफ-स्टेकवर अधिक](/developers/docs/consensus-mechanisms/pos/) + +## तुम्ही पाहून शिकणारे आहात का? {#visual-learner} + + + +## अधिक वाचन {#further-reading} + +- [बहुमताचा हल्ला](https://en.bitcoin.it/wiki/Majority_attack) +- [सेटलमेंटच्या अंतिमातेवर](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### व्हिडिओ {#videos} + +- [प्रूफ-ऑफ-वर्क प्रोटोकॉलचे तांत्रिक स्पष्टीकरण](https://youtu.be/9V1bipPkCTU) + +## संबंधित विषय {#related-topics} + +- [मायनिंग](/developers/docs/consensus-mechanisms/pow/mining/) +- [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) +- [प्रूफ-ऑफ-अथॉरिटी](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..1d811f64948 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "मायनिंग" +description: "Ethereum वर मायनिंग कसे कार्य करते याचे स्पष्टीकरण." +lang: mr +--- + + + + + +प्रूफ-ऑफ-वर्क आता Ethereum च्या एकमत यंत्रणेचा आधार नाही, याचा अर्थ मायनिंग बंद करण्यात आले आहे. त्याऐवजी, Ethereum ETH स्टेक करणाऱ्या व्हॅलिडेटर्सद्वारे सुरक्षित आहे. तुम्ही आजच तुमचे ETH स्टेक करणे सुरू करू शकता. द मर्ज, प्रूफ-ऑफ-स्टेक, आणि स्टेकिंग यावर अधिक वाचा. हे पान केवळ ऐतिहासिक माहितीसाठी आहे. + + + + +## पूर्वतयारी {#prerequisites} + +हे पान अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [transactions](/developers/docs/transactions/), [blocks](/developers/docs/blocks/) आणि [proof-of-work](/developers/docs/consensus-mechanisms/pow/) याबद्दल वाचा. + +## Ethereum मायनिंग म्हणजे काय? {#what-is-ethereum-mining} + +Ethereum च्या आता कालबाह्य झालेल्या प्रूफ-ऑफ-वर्क आर्किटेक्चरमध्ये Ethereum ब्लॉकचेनमध्ये जोडण्यासाठी व्यवहारांचा ब्लॉक तयार करण्याची प्रक्रिया म्हणजे मायनिंग. + +मायनिंग हा शब्द क्रिप्टोकरन्सीसाठी सोन्याच्या साधर्म्याच्या संदर्भात उद्भवला आहे. सोने किंवा मौल्यवान धातू दुर्मिळ आहेत, तसेच डिजिटल टोकन देखील दुर्मिळ आहेत, आणि प्रूफ-ऑफ-वर्क प्रणालीमध्ये एकूण व्हॉल्यूम वाढवण्याचा एकमेव मार्ग म्हणजे मायनिंग. प्रूफ-ऑफ-वर्क Ethereum मध्ये, जारी करण्याचा एकमेव मार्ग मायनिंगद्वारे होता. तथापि, सोने किंवा मौल्यवान धातूंच्या विपरीत, Ethereum मायनिंग हे ब्लॉकचेनमध्ये ब्लॉक तयार करून, सत्यापित करून, प्रकाशित करून आणि प्रसारित करून नेटवर्क सुरक्षित करण्याचा मार्ग होता. + +इथर मायनिंग = नेटवर्क सुरक्षित करणे + +कोणत्याही प्रूफ-ऑफ-वर्क ब्लॉकचेनचा मायनिंग हा जीवनप्रवाह आहे. Ethereum मायनर्स - सॉफ्टवेअर चालवणारे संगणक - प्रूफ-ऑफ-स्टेकवर संक्रमणापूर्वी व्यवहारांवर प्रक्रिया करण्यासाठी आणि ब्लॉक तयार करण्यासाठी त्यांचा वेळ आणि संगणकीय शक्ती वापरत होते. + +## मायनर्स का अस्तित्वात आहेत? {#why-do-miners-exist} + +Ethereum सारख्या विकेंद्रित प्रणालींमध्ये, व्यवहारांच्या क्रमावर प्रत्येकजण सहमत आहे याची खात्री करणे आवश्यक आहे. मायनर्सने ब्लॉक तयार करण्यासाठी संगणकीयदृष्ट्या कठीण कोडी सोडवून हे घडवून आणण्यास मदत केली, ज्यामुळे नेटवर्क हल्ल्यांपासून सुरक्षित राहिले. + +[प्रूफ-ऑफ-वर्कबद्दल अधिक](/developers/docs/consensus-mechanisms/pow/) + +पूर्वी कोणीही आपल्या संगणकाचा वापर करून Ethereum नेटवर्कवर मायनिंग करू शकत होते. तथापि, प्रत्येकजण फायदेशीरपणे इथर (ETH) माइन करू शकत नव्हते. बऱ्याच प्रकरणांमध्ये, मायनर्सना समर्पित संगणक हार्डवेअर खरेदी करावे लागत होते आणि स्वस्त उर्जा स्त्रोतांमध्ये प्रवेश मिळवावा लागत होता. मायनिंगच्या संबंधित खर्चाची भरपाई करण्यासाठी सरासरी संगणकाला पुरेसे ब्लॉक रिवॉर्ड मिळण्याची शक्यता कमी होती. + +### मायनिंगचा खर्च {#cost-of-mining} + +- मायनिंग रिग तयार करण्यासाठी आणि देखरेखीसाठी आवश्यक हार्डवेअरचा संभाव्य खर्च +- मायनिंग रिगला वीज पुरवण्याचा खर्च +- जर तुम्ही पूलमध्ये मायनिंग करत असाल, तर हे पूल्स सामान्यतः पूलद्वारे तयार केलेल्या प्रत्येक ब्लॉकवर एक निश्चित % शुल्क आकारतात +- मायनिंग रिगला समर्थन देण्यासाठी उपकरणांचा संभाव्य खर्च (वायुवीजन, ऊर्जा देखरेख, विद्युत वायरिंग, इ.) + +मायनिंगच्या नफाक्षमतेबद्दल अधिक जाणून घेण्यासाठी, [Etherscan](https://etherscan.io/ether-mining-calculator) द्वारे प्रदान केलेल्या मायनिंग कॅल्क्युलेटरचा वापर करा. + +## Ethereum व्यवहार कसे माइन केले गेले {#how-ethereum-transactions-were-mined} + +खालील माहिती Ethereum प्रूफ-ऑफ-वर्कमध्ये व्यवहार कसे माइन केले जात होते याचा आढावा देते. Ethereum प्रूफ-ऑफ-स्टेकसाठी या प्रक्रियेचे साधर्म्य असलेले वर्णन [येथे](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) आढळू शकते. + +1. एक वापरकर्ता काही [खात्याच्या](/developers/docs/accounts/) खासगी की सह [व्यवहार](/developers/docs/transactions/) विनंती लिहितो आणि त्यावर सही करतो. +2. वापरकर्ता काही [नोडवरून](/developers/docs/nodes-and-clients/) संपूर्ण Ethereum नेटवर्कवर व्यवहार विनंती प्रसारित करतो. +3. नवीन व्यवहार विनंतीबद्दल ऐकल्यावर, Ethereum नेटवर्कमधील प्रत्येक नोड ती विनंती त्यांच्या स्थानिक मेमपूलमध्ये जोडतो, जी अशा सर्व व्यवहार विनंत्यांची यादी आहे ज्यांच्याबद्दल त्यांनी ऐकले आहे परंतु अद्याप ब्लॉकचेनमध्ये एका ब्लॉकमध्ये समाविष्ट केल्या गेल्या नाहीत. +4. एका क्षणी, एक मायनिंग नोड अनेक डझन किंवा शंभर व्यवहार विनंत्या एका संभाव्य [ब्लॉकमध्ये](/developers/docs/blocks/) एकत्र करतो, अशा प्रकारे की ब्लॉक गॅस मर्यादेच्या आत राहून ते कमावत असलेले [व्यवहार शुल्क](/developers/docs/gas/) जास्तीत जास्त होईल. त्यानंतर मायनिंग नोड: + 1. प्रत्येक व्यवहार विनंतीच्या वैधतेची पडताळणी करते (उदा., कोणीही अशा खात्यातून इथर हस्तांतरित करण्याचा प्रयत्न करत नाही ज्यासाठी त्यांनी स्वाक्षरी तयार केलेली नाही, विनंती सदोष नाही, इ.), आणि नंतर विनंतीचा कोड कार्यान्वित करते, ज्यामुळे त्यांच्या EVM च्या स्थानिक प्रतीची स्थिती बदलते. मायनर अशा प्रत्येक व्यवहार विनंतीसाठीचे व्यवहार शुल्क स्वतःच्या खात्यात जमा करतो. + 2. ब्लॉकमधील सर्व व्यवहार विनंत्या स्थानिक EVM प्रतीवर सत्यापित आणि कार्यान्वित झाल्यावर, संभाव्य ब्लॉकसाठी प्रूफ-ऑफ-वर्क “वैधतेचे प्रमाणपत्र” तयार करण्याची प्रक्रिया सुरू करते. +5. अखेरीस, एक मायनर एका ब्लॉकसाठी प्रमाणपत्र तयार करणे पूर्ण करेल ज्यात आपली विशिष्ट व्यवहार विनंती समाविष्ट आहे. त्यानंतर मायनर पूर्ण झालेला ब्लॉक प्रसारित करतो, ज्यात प्रमाणपत्र आणि दाव्या केलेल्या नवीन EVM स्थितीचा चेकसम समाविष्ट असतो. +6. इतर नोड्स नवीन ब्लॉकबद्दल ऐकतात. ते प्रमाणपत्राची पडताळणी करतात, ब्लॉकवरील सर्व व्यवहार स्वतः कार्यान्वित करतात (आपल्या वापरकर्त्याने मूळतः प्रसारित केलेला व्यवहार धरून), आणि सर्व व्यवहार कार्यान्वित झाल्यानंतर त्यांच्या नवीन EVM स्थितीचा चेकसम मायनरच्या ब्लॉकने दावा केलेल्या स्थितीच्या चेकसमशी जुळतो याची पडताळणी करतात. केवळ तेव्हाच हे नोड्स हा ब्लॉक त्यांच्या ब्लॉकचेनच्या शेवटी जोडतात आणि नवीन EVM स्थितीला कॅनॉनिकल स्थिती म्हणून स्वीकारतात. +7. प्रत्येक नोड नवीन ब्लॉकमधील सर्व व्यवहार त्यांच्या अपूर्ण व्यवहार विनंत्यांच्या स्थानिक मेमपूलमधून काढून टाकतो. +8. नेटवर्कमध्ये सामील होणारे नवीन नोड्स क्रमाने सर्व ब्लॉक डाउनलोड करतात, ज्यात आपल्या आवडीचा व्यवहार असलेला ब्लॉक समाविष्ट आहे. ते स्थानिक EVM प्रतीची सुरुवात करतात (जी रिक्त-स्थिती EVM म्हणून सुरू होते), आणि नंतर त्यांच्या स्थानिक EVM प्रतीवर प्रत्येक ब्लॉकमधील प्रत्येक व्यवहार कार्यान्वित करण्याच्या प्रक्रियेतून जातात, आणि मार्गातील प्रत्येक ब्लॉकवर स्थिती चेकसमची पडताळणी करतात. + +प्रत्येक व्यवहार एकदाच माइन केला जातो (नवीन ब्लॉकमध्ये समाविष्ट केला जातो आणि पहिल्यांदा प्रसारित केला जातो), परंतु कॅनॉनिकल EVM स्थिती पुढे नेण्याच्या प्रक्रियेत प्रत्येक सहभागीद्वारे तो कार्यान्वित आणि सत्यापित केला जातो. हे ब्लॉकचेनच्या केंद्रीय मंत्रांपैकी एक अधोरेखित करते: **विश्वास ठेवू नका, पडताळणी करा**. + +## ओमर (अंकल) ब्लॉक्स {#ommer-blocks} + +प्रूफ-ऑफ-वर्कवर ब्लॉक मायनिंग संभाव्य होते, म्हणजे कधीकधी नेटवर्क लेटन्सीमुळे दोन वैध ब्लॉक एकाच वेळी प्रकाशित होत असत. या प्रकरणात, प्रोटोकॉलला प्रस्तावित केलेल्या, समाविष्ट न केलेल्या वैध ब्लॉकला अंशतः पुरस्कृत करून मायनर्सप्रती निष्पक्षता सुनिश्चित करताना सर्वात लांब (आणि म्हणून सर्वात "वैध") साखळी निश्चित करावी लागत होती. यामुळे नेटवर्कच्या अधिक विकेंद्रीकरणाला प्रोत्साहन मिळाले कारण लहान मायनर्स, ज्यांना जास्त लेटन्सीचा सामना करावा लागू शकतो, ते [ओमर](/glossary/#ommer) ब्लॉक रिवॉर्ड्सद्वारे परतावा मिळवू शकत होते. + +"ओमर" हा शब्द पॅरेंट ब्लॉकच्या भावंडासाठी पसंतीचा लिंग-तटस्थ शब्द आहे, परंतु याला कधीकधी "अंकल" असेही संबोधले जाते. **Ethereum च्या प्रूफ-ऑफ-स्टेककडे जाण्यापासून, ओमर ब्लॉक आता माइन केले जात नाहीत** कारण प्रत्येक स्लॉटमध्ये फक्त एकच प्रस्तावक निवडला जातो. माइन केलेल्या ओमर ब्लॉक्सचा [ऐतिहासिक चार्ट](https://ycharts.com/indicators/ethereum_uncle_rate) पाहून तुम्ही हा बदल पाहू शकता. + +## एक दृश्यात्मक डेमो {#a-visual-demo} + +ऑस्टिन तुम्हाला मायनिंग आणि प्रूफ-ऑफ-वर्क ब्लॉकचेनबद्दल माहिती देत असताना पहा. + + + +## मायनिंग अल्गोरिदम {#mining-algorithm} + +Ethereum मेननेटने फक्त एकच मायनिंग अल्गोरिदम वापरला - ['इथॅश'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). इथॅश हा मूळ R&D अल्गोरिदमचा उत्तराधिकारी होता, जो ['डॅगर-हाशिमोटो'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) म्हणून ओळखला जातो. + +[मायनिंग अल्गोरिदमबद्दल अधिक](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## संबंधित विषय {#related-topics} + +- [गॅस](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [प्रूफ-ऑफ-वर्क](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..74bac17d98b --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,329 @@ +--- +title: Dagger-Hashimoto +description: "Dagger-Hashimoto अल्गोरिदमचा एक सविस्तर आढावा." +lang: mr +--- + +Dagger-Hashimoto हे Ethereum च्या मायनिंग अल्गोरिदमसाठी मूळ संशोधन अंमलबजावणी आणि विनिर्देश होते. Dagger-Hashimoto ची जागा [Ethash](#ethash) ने घेतली. 15 सप्टेंबर 2022 रोजी [द मर्ज](/roadmap/merge/) येथे मायनिंग पूर्णपणे बंद करण्यात आले. तेव्हापासून, त्याऐवजी [प्रुफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos) यंत्रणा वापरून Ethereum सुरक्षित केले गेले आहे. हे पान ऐतिहासिक माहितीसाठी आहे - येथील माहिती मर्ज-नंतरच्या Ethereum साठी आता संबंधित नाही. + +## पूर्वतयारी {#prerequisites} + +हे पान अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [प्रुफ-ऑफ-वर्क कन्सेंसस](/developers/docs/consensus-mechanisms/pow), [मायनिंग](/developers/docs/consensus-mechanisms/pow/mining), आणि [मायनिंग अल्गोरिदम](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) बद्दल वाचा. + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto चे उद्दिष्ट दोन उद्दिष्टे पूर्ण करणे आहे: + +1. **ASIC-प्रतिरोध**: अल्गोरिदमसाठी विशेष हार्डवेअर तयार करण्याचा फायदा शक्य तितका कमी असावा +2. **लाईट क्लायंट पडताळणीक्षमता**: लाईट क्लायंटद्वारे एका ब्लॉकची कार्यक्षमतेने पडताळणी करता आली पाहिजे. + +एका अतिरिक्त बदलासह, आम्ही इच्छित असल्यास तिसरे उद्दिष्ट कसे पूर्ण करायचे हे देखील निर्दिष्ट करतो, परंतु अतिरिक्त गुंतागुंतीच्या किंमतीवर: + +**पूर्ण चेन स्टोरेज**: मायनिंगसाठी संपूर्ण ब्लॉकचेन स्थितीचा स्टोरेज आवश्यक असावा (Ethereum स्टेट ट्राईच्या अनियमित रचनेमुळे, आम्हाला अपेक्षा आहे की काही प्रूनिंग शक्य होईल, विशेषत: काही वारंवार वापरल्या जाणाऱ्या कॉन्ट्रॅक्ट्सची, परंतु आम्हाला हे कमी करायचे आहे). + +## DAG जनरेशन {#dag-generation} + +अल्गोरिदमसाठीचा कोड खाली Python मध्ये परिभाषित केला जाईल. प्रथम, आम्ही निर्दिष्ट अचूकतेचे अनसाईन्ड इंट्स स्ट्रिंग्समध्ये मार्शल करण्यासाठी `encode_int` देतो. त्याचा व्यस्त देखील दिला आहे: + +```python +NUM_BITS = 512 + +def encode_int(x): + "बिग-एंडियन स्कीम वापरून x या पूर्णांकाला 64 वर्णांच्या स्ट्रिंगमध्ये एन्कोड करा" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "बिग-एंडियन स्कीम वापरून स्ट्रिंगमधून x या पूर्णांकाला अनएन्कोड करा" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +पुढे आपण असे गृहीत धरतो की `sha3` हे एक फंक्शन आहे जे एक पूर्णांक घेते आणि एक पूर्णांक आउटपुट देते, आणि `dbl_sha3` हे एक डबल-sha3 फंक्शन आहे; हा संदर्भ कोड अंमलबजावणीमध्ये रूपांतरित करत असल्यास वापरा: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### मापदंड {#parameters} + +अल्गोरिदमसाठी वापरलेले मापदंड आहेत: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # 2**512 पेक्षा कमी सर्वात मोठी सुरक्षित अविभाज्य संख्या + +params = { + "n": 4000055296 * 8 // NUM_BITS, # डेटासेटचा आकार (4 गिगाबाईट्स); 65536 च्या पटीत असणे आवश्यक आहे + "n_inc": 65536, # प्रति कालावधी n च्या मूल्यात वाढ; 65536 च्या पटीत असणे आवश्यक आहे + # epochtime=20000 सह प्रति वर्ष 882 MB वाढ देते + "cache_size": 2500, # लाईट क्लायंटच्या कॅशेचा आकार (लाईट क्लायंटद्वारे निवडला जाऊ शकतो; अल्गो स्पेसिफिकेशनचा भाग नाही) + "diff": 2**14, # अडचण (ब्लॉक मूल्यांकनादरम्यान समायोजित) + "epochtime": 100000, # ब्लॉक्समधील एका इपॉकची लांबी (डेटासेट किती वेळा अपडेट केला जातो) + "k": 1, # नोडच्या पॅरेंट्सची संख्या + "w": w, # मॉड्यूलर घातांक हॅशिंगसाठी वापरले जाते + "accesses": 200, # हाशिमोटो दरम्यान डेटासेट प्रवेशांची संख्या + "P": SAFE_PRIME_512 # हॅशिंग आणि यादृच्छिक संख्या निर्मितीसाठी सुरक्षित अविभाज्य संख्या +} +``` + +या प्रकरणात `P` ही एक अविभाज्य संख्या आहे जी अशी निवडली आहे की `log₂(P)` 512 पेक्षा किंचित कमी आहे, जे आपल्या संख्या दर्शवण्यासाठी आपण वापरत असलेल्या 512 बिट्सशी जुळते. लक्षात घ्या की प्रत्यक्षात DAG चा फक्त उत्तरार्ध संग्रहित करणे आवश्यक आहे, त्यामुळे वास्तविक रॅमची आवश्यकता 1 GB पासून सुरू होते आणि प्रति वर्ष 441 MB ने वाढते. + +### डॅगर ग्राफ बिल्डिंग {#dagger-graph-building} + +डॅगर ग्राफ बिल्डिंग प्रिमिटिव्ह खालीलप्रमाणे परिभाषित केले आहे: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +मूलत:, हे एकाच नोड, `sha3(seed)` पासून ग्राफ सुरू करते आणि तेथून यादृच्छिक मागील नोड्सवर आधारित इतर नोड्स क्रमशः जोडण्यास सुरुवात करते. जेव्हा एक नवीन नोड तयार होतो, तेव्हा सीडची एक मॉड्यूलर पॉवर `i` पेक्षा कमी असलेले काही निर्देशांक यादृच्छिकपणे निवडण्यासाठी मोजली जाते (वर `x % i` वापरून), आणि त्या निर्देशांकांवर असलेल्या नोड्सची मूल्ये `x` साठी नवीन मूल्य तयार करण्यासाठी एका गणनेत वापरली जातात, जे नंतर एका लहान प्रुफ-ऑफ-वर्क फंक्शनमध्ये (XOR वर आधारित) दिले जाते, जेणेकरून शेवटी `i` निर्देशांकावर ग्राफचे मूल्य तयार होते. या विशिष्ट डिझाइनमागील तर्क म्हणजे DAG च्या क्रमशः प्रवेशासाठी सक्ती करणे; जोपर्यंत वर्तमान मूल्य ज्ञात नाही तोपर्यंत DAG चे पुढील मूल्य निर्धारित केले जाऊ शकत नाही. शेवटी, मॉड्यूलर घातांक परिणामास पुढे हॅश करते. + +हा अल्गोरिदम संख्या सिद्धांतातील अनेक परिणामांवर अवलंबून आहे. चर्चेसाठी खालील परिशिष्ट पहा. + +## लाईट क्लायंट मूल्यांकन {#light-client-evaluation} + +वरील ग्राफ रचनेचा उद्देश ग्राफमधील प्रत्येक नोडची पुनर्रचना करण्यास परवानगी देणे आहे, फक्त थोड्या संख्येच्या नोड्सच्या सबट्रीची गणना करून आणि फक्त थोड्या प्रमाणात सहायक मेमरीची आवश्यकता असते. लक्षात घ्या की k=1 सह, सबट्री ही DAG मधील पहिल्या घटकापर्यंत जाणारी मूल्यांची एक साखळी आहे. + +DAG साठी लाईट क्लायंट कंप्युटिंग फंक्शन खालीलप्रमाणे कार्य करते: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +मूलत:, हे वरील अल्गोरिदमचे एक पुनर्लेखन आहे जे संपूर्ण DAG साठी मूल्ये मोजण्याचे लूप काढून टाकते आणि पूर्वीच्या नोड लूकअपला रिकर्सिव्ह कॉल किंवा कॅशे लूकअपसह बदलते. लक्षात घ्या की `k=1` साठी कॅशे अनावश्यक आहे, जरी पुढील ऑप्टिमायझेशन प्रत्यक्षात DAG ची पहिली काही हजार मूल्ये पूर्व-गणना करते आणि ते गणनेसाठी स्थिर कॅशे म्हणून ठेवते; याची कोड अंमलबजावणी परिशिष्टात पहा. + +## DAGs चे डबल बफर {#double-buffer} + +एका पूर्ण क्लायंटमध्ये, वरील सूत्राद्वारे तयार केलेल्या 2 DAGs चा एक [_डबल बफर_](https://wikipedia.org/wiki/Multiple_buffering) वापरला जातो. कल्पना अशी आहे की वरील पॅरामीटर्सनुसार प्रत्येक `epochtime` ब्लॉक संख्येवर DAGs तयार केले जातात. क्लायंटने तयार केलेला नवीनतम DAG वापरण्याऐवजी, तो मागील एक वापरतो. याचा फायदा हा आहे की ते DAGs वेळेनुसार बदलण्याची परवानगी देते, ज्यात मायनर्सना अचानक सर्व डेटाची पुनर्गणना करावी लागते असा टप्पा समाविष्ट करण्याची आवश्यकता नाही. अन्यथा, नियमित अंतराने चेन प्रक्रियेत अचानक तात्पुरती मंदी येण्याची आणि केंद्रीकरण नाटकीयरित्या वाढण्याची शक्यता आहे. त्यामुळे सर्व डेटाची पुनर्गणना होण्यापूर्वी त्या काही मिनिटांत 51% हल्ल्याचा धोका असतो. + +ब्लॉकसाठी कार्य मोजण्यासाठी वापरल्या जाणाऱ्या DAGs चा संच तयार करण्यासाठी वापरलेला अल्गोरिदम खालीलप्रमाणे आहे: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # बॅक बफर शक्य नाही, फक्त फ्रंट बफर तयार करा + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +मूळ हाशिमोटोमागील कल्पना ब्लॉकचेनला डेटासेट म्हणून वापरणे आहे, एक गणना करणे जी ब्लॉकचेनमधून N निर्देशांक निवडते, त्या निर्देशांकांवरील व्यवहार गोळा करते, या डेटाचे XOR करते आणि परिणामाचा हॅश परत करते. थॅडियस ड्रायजाचा मूळ अल्गोरिदम, सुसंगततेसाठी Python मध्ये अनुवादित, खालीलप्रमाणे आहे: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +दुर्दैवाने, हाशिमोटोला रॅम हार्ड मानले जात असले तरी, ते 256-बिट अंकगणितावर अवलंबून आहे, ज्यात लक्षणीय संगणकीय ओव्हरहेड आहे. तथापि, या समस्येचे निराकरण करण्यासाठी Dagger-Hashimoto आपल्या डेटासेटला अनुक्रमित करताना फक्त सर्वात कमी लक्षणीय 64 बिट्स वापरते. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +डबल SHA3 चा वापर शून्य-डेटा, जवळपास-तत्काळ पूर्व-पडताळणीसाठी परवानगी देतो, फक्त हे सत्यापित करतो की योग्य मध्यवर्ती मूल्य प्रदान केले गेले होते. प्रुफ-ऑफ-वर्कचा हा बाह्य थर अत्यंत ASIC-अनुकूल आणि बऱ्यापैकी कमकुवत आहे, परंतु DDoS आणखी कठीण करण्यासाठी अस्तित्वात आहे कारण असा ब्लॉक तयार करण्यासाठी ते लहान काम करणे आवश्यक आहे जो त्वरित नाकारला जाणार नाही. ही लाईट-क्लायंट आवृत्ती आहे: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## मायनिंग आणि पडताळणी {#mining-and-verifying} + +आता, आपण हे सर्व मायनिंग अल्गोरिदममध्ये एकत्र ठेवूया: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +हा पडताळणी अल्गोरिदम आहे: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +लाईट-क्लायंट अनुकूल पडताळणी: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +तसेच, लक्षात घ्या की Dagger-Hashimoto ब्लॉक हेडरवर अतिरिक्त आवश्यकता लादते: + +- दोन-स्तरीय पडताळणी कार्य करण्यासाठी, ब्लॉक हेडरमध्ये नॉन्स आणि मध्यवर्ती मूल्य दोन्ही प्री-sha3 असणे आवश्यक आहे +- कुठेतरी, ब्लॉक हेडरने वर्तमान सीडसेटचा sha3 संग्रहित करणे आवश्यक आहे + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## परिशिष्ट {#appendix} + +वर नमूद केल्याप्रमाणे, DAG जनरेशनसाठी वापरलेले RNG संख्या सिद्धांतातील काही परिणामांवर अवलंबून आहे. प्रथम, आम्ही आश्वासन देतो की लेमर RNG जे `picker` व्हेरिएबलचा आधार आहे त्याचा कालावधी मोठा आहे. दुसरे, आम्ही दाखवतो की `pow(x,3,P)` `x` ला `1` किंवा `P-1` वर मॅप करणार नाही, जर `x ∈ [2,P-2]` पासून सुरू होत असेल. शेवटी, आम्ही दाखवतो की `pow(x,3,P)` चा टक्कर दर कमी आहे जेव्हा त्याला हॅशिंग फंक्शन म्हणून मानले जाते. + +### लेमर यादृच्छिक संख्या जनरेटर {#lehmer-random-number} + +`produce_dag` फंक्शनला निःपक्षपाती यादृच्छिक संख्या तयार करण्याची आवश्यकता नसली तरी, एक संभाव्य धोका आहे की `seed**i % P` फक्त काही मोजकीच मूल्ये घेते. हे पॅटर्न ओळखणाऱ्या मायनर्सना जे ओळखत नाहीत त्यांच्यापेक्षा फायदा देऊ शकते. + +हे टाळण्यासाठी, संख्या सिद्धांतातील एका निकालाचा आधार घेतला जातो. एक [_सुरक्षित अविभाज्य संख्या_](https://en.wikipedia.org/wiki/Safe_prime) अशी अविभाज्य संख्या `P` म्हणून परिभाषित केली जाते की `(P-1)/2` देखील अविभाज्य असते. [गुणाकार गट](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ` च्या सदस्य `x` चा _ऑर्डर_ किमान `m` म्हणून परिभाषित केला जातो जसे की 
xᵐ mod P ≡ 1
+या व्याख्या दिल्यावर, आपल्याकडे आहे: + +> निरीक्षण 1. `x` हा सुरक्षित अविभाज्य `P` साठी गुणाकार गट `ℤ/Pℤ` चा सदस्य असू द्या. जर `x mod P ≠ 1 mod P` आणि `x mod P ≠ P-1 mod P` असेल, तर `x` चा ऑर्डर `P-1` किंवा `(P-1)/2` आहे. + +_पुरावा_. `P` एक सुरक्षित अविभाज्य असल्यामुळे, नंतर [लाग्रेंजच्या प्रमेयानुसार][lagrange] आपल्याकडे `x` चा ऑर्डर `1`, `2`, `(P-1)/2`, किंवा `P-1` आहे. + +`x` चा ऑर्डर `1` असू शकत नाही, कारण फर्माच्या लहान प्रमेयानुसार आपल्याकडे आहे: + +
xP-1 mod P ≡ 1
+ +म्हणून `x` हे `ℤ/nℤ` चे एक गुणाकार ओळख असणे आवश्यक आहे, जे अद्वितीय आहे. आपण गृहित धरल्याप्रमाणे `x ≠ 1` गृहित धरल्यामुळे, हे शक्य नाही. + +`x` चा ऑर्डर `2` असू शकत नाही जोपर्यंत `x = P-1` नाही, कारण हे `P` अविभाज्य असल्याचे उल्लंघन करेल. + +वरील प्रतिपादनावरून, आपण ओळखू शकतो की `(picker * init) % P` ची पुनरावृत्ती केल्यास चक्राची लांबी किमान `(P-1)/2` असेल. हे कारण आपण `P` ला दोनच्या उच्च घातांकाच्या अंदाजे समान असलेली एक सुरक्षित अविभाज्य संख्या म्हणून निवडले आहे, आणि `init` हे `[2,2**256+1]` या अंतराळात आहे. `P` चे परिमाण पाहता, आपण मॉड्यूलर घातांकातून चक्राची अपेक्षा कधीही करू नये. + +जेव्हा आपण DAG मधील पहिली सेल (व्हेरिएबल `init` म्हणून लेबल केलेले) नियुक्त करत असतो, तेव्हा आपण `pow(sha3(seed) + 2, 3, P)` मोजतो. पहिल्या दृष्टीक्षेपात, हे परिणाम `1` किंवा `P-1` नसल्याची हमी देत नाही. तथापि, `P-1` एक सुरक्षित अविभाज्य असल्यामुळे, आपल्याकडे खालील अतिरिक्त आश्वासन आहे, जे निरीक्षण 1 चे एक उपप्रमेय आहे: + +> निरीक्षण २. `x` हा सुरक्षित अविभाज्य `P` साठी गुणाकार गट `ℤ/Pℤ` चा सदस्य असू द्या, आणि `w` एक नैसर्गिक संख्या असू द्या. जर `x mod P ≠ 1 mod P` आणि `x mod P ≠ P-1 mod P` असेल, तसेच `w mod P ≠ P-1 mod P` आणि `w mod P ≠ 0 mod P` असेल, तर `xʷ mod P ≠ 1 mod P` आणि `xʷ mod P ≠ P-1 mod P` + +### हॅश फंक्शन म्हणून मॉड्यूलर घातांक {#modular-exponentiation} + +`P` आणि `w` च्या काही विशिष्ट मूल्यांसाठी, `pow(x, w, P)` या फंक्शनमध्ये अनेक टकराव असू शकतात. उदाहरणार्थ, `pow(x,9,19)` फक्त `{1,18}` ही मूल्ये घेते. + +`P` अविभाज्य आहे हे लक्षात घेता, मॉड्यूलर घातांक हॅशिंग फंक्शनसाठी योग्य `w` खालील निकालाचा वापर करून निवडला जाऊ शकतो: + +> निरीक्षण 3. `P` एक अविभाज्य संख्या असू द्या; `w` आणि `P-1` सापेक्ष अविभाज्य आहेत जर आणि फक्त जर `ℤ/Pℤ` मधील सर्व `a` आणि `b` साठी:
`aʷ mod P ≡ bʷ mod P` जर आणि फक्त जर `a mod P ≡ b mod P`
+ +म्हणून, `P` अविभाज्य आहे आणि `w` हे `P-1` च्या सापेक्ष अविभाज्य आहे हे लक्षात घेता, आपल्याकडे `|{pow(x, w, P) : x ∈ ℤ}| = P` आहे, याचा अर्थ असा की हॅशिंग फंक्शनचा टक्कर दर शक्य तितका किमान आहे. + +आपण निवडल्याप्रमाणे `P` एक सुरक्षित अविभाज्य संख्या आहे या विशेष बाबतीत, तर `P-1` ला फक्त 1, 2, `(P-1)/2` आणि `P-1` हे घटक आहेत. `P` > 7 असल्यामुळे, आपल्याला माहित आहे की 3 हे `P-1` च्या सापेक्ष अविभाज्य आहे, म्हणून `w=3` वरील प्रतिपादनाची पूर्तता करते. + +## अधिक कार्यक्षम कॅशे-आधारित मूल्यांकन अल्गोरिदम {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..c6d4298d2d7 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1019 @@ +--- +title: "एथहॅश" +description: "एथहॅश अल्गोरिदमवर एक विस्तृत नजर." +lang: mr +--- + + + + + + एथहॅश हा Ethereum चा प्रूफ-ऑफ-वर्क मायनिंग अल्गोरिदम होता. प्रूफ-ऑफ-वर्क आता **पूर्णपणे बंद** केले आहे आणि Ethereum आता त्याऐवजी [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) वापरून सुरक्षित केले आहे. [द मर्ज](/roadmap/merge/), [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos/) आणि [स्टेकिंग](/staking/) वर अधिक वाचा. हे पृष्ठ केवळ ऐतिहासिक माहितीसाठी आहे! + + + + +एथहॅश हे [डॅगर-हाशिमोटो](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) अल्गोरिदमची सुधारित आवृत्ती आहे. एथहॅश प्रूफ-ऑफ-वर्क हे [मेमरी हार्ड](https://wikipedia.org/wiki/Memory-hard_function) आहे, ज्यामुळे अल्गोरिदम ASIC प्रतिरोधक बनेल असे मानले जात होते. अखेरीस एथहॅश ASICs विकसित केले गेले परंतु प्रूफ-ऑफ-वर्क बंद होईपर्यंत GPU मायनिंग हा एक व्यवहार्य पर्याय होता. इतर नॉन-Ethereum प्रूफ-ऑफ-वर्क नेटवर्क्सवर इतर कॉइन्स माइन करण्यासाठी एथहॅश अजूनही वापरले जाते. + +## एथहॅश कसे कार्य करते? {#how-does-ethash-work} + +मेमरी हार्डनेस एका प्रूफ ऑफ वर्क अल्गोरिदमद्वारे प्राप्त केली जाते ज्यासाठी नॉन्स आणि ब्लॉक हेडरवर अवलंबून असलेल्या निश्चित रिसोर्समधून उपसंचांची निवड करणे आवश्यक असते. या रिसोर्सला (आकारात काही गीगाबाईट्स) DAG म्हटले जाते. DAG प्रत्येक ३०००० ब्लॉक्सनंतर बदलला जातो, जो ~१२५-तासांचा कालावधी आहे ज्याला इपॉक (अंदाजे ५.२ दिवस) म्हणतात आणि तो तयार होण्यासाठी थोडा वेळ लागतो. DAG केवळ ब्लॉकच्या उंचीवर अवलंबून असल्याने, तो पूर्व-उत्पन्न केला जाऊ शकतो, परंतु तसे नसल्यास क्लायंटला ब्लॉक तयार करण्यासाठी या प्रक्रियेच्या शेवटपर्यंत थांबावे लागेल. जर क्लायंट्सनी वेळेपूर्वी DAGs पूर्व-उत्पन्न आणि कॅशे केले नाहीत, तर नेटवर्कला प्रत्येक इपॉक संक्रमणावर मोठ्या ब्लॉक विलंबाचा सामना करावा लागू शकतो. लक्षात घ्या की प्रूफ-ऑफ-वर्क सत्यापित करण्यासाठी DAG तयार करण्याची आवश्यकता नाही, ज्यामुळे कमी CPU आणि कमी मेमरीसह सत्यापन शक्य होते. + +अल्गोरिदम ज्या सामान्य मार्गाचा अवलंब करतो तो खालीलप्रमाणे आहे: + +1. एक **सीड** अस्तित्वात आहे जी प्रत्येक ब्लॉकसाठी त्या बिंदूपर्यंतच्या ब्लॉक हेडर्समधून स्कॅन करून मोजली जाऊ शकते. +2. सीडमधून, कोणीही **१६ MB स्युडोरँडम कॅशे** मोजू शकतो. लाइट क्लायंट कॅशे संग्रहित करतात. +3. कॅशेमधून, आम्ही **१ GB डेटासेट** तयार करू शकतो, ज्यामध्ये डेटासेटमधील प्रत्येक आयटम कॅशेमधील केवळ काही आयटमवर अवलंबून असतो. पूर्ण क्लायंट आणि मायनर्स डेटासेट संग्रहित करतात. डेटासेट वेळेनुसार रेषीयपणे वाढतो. +4. मायनिंगमध्ये डेटासेटचे यादृच्छिक स्लाइस घेणे आणि त्यांना एकत्र हॅश करणे समाविष्ट आहे. तुम्हाला आवश्यक असलेल्या डेटासेटचे विशिष्ट तुकडे पुन्हा तयार करण्यासाठी कॅशे वापरून कमी मेमरीसह सत्यापन केले जाऊ शकते, म्हणून तुम्हाला फक्त कॅशे संग्रहित करण्याची आवश्यकता आहे. + +मोठा डेटासेट प्रत्येक ३०००० ब्लॉक्सनंतर एकदा अपडेट केला जातो, त्यामुळे मायनरचा बहुतांश प्रयत्न डेटासेट वाचण्यात जाईल, त्यात बदल करण्यात नाही. + +## व्याख्या {#definitions} + +आम्ही खालील व्याख्या वापरतो: + +``` +WORD_BYTES = 4 # शब्दात बाइट्स +DATASET_BYTES_INIT = 2**30 # जेनेसिसवेळी डेटासेटमधील बाइट्स +DATASET_BYTES_GROWTH = 2**23 # प्रति इपॉक डेटासेट वाढ +CACHE_BYTES_INIT = 2**24 # जेनेसिसवेळी कॅशेमधील बाइट्स +CACHE_BYTES_GROWTH = 2**17 # प्रति इपॉक कॅशे वाढ +CACHE_MULTIPLIER=1024 # कॅशेच्या तुलनेत DAG चा आकार +EPOCH_LENGTH = 30000 # प्रति इपॉक ब्लॉक्स +MIX_BYTES = 128 # मिक्सची रुंदी +HASH_BYTES = 64 # बाइट्समध्ये हॅशची लांबी +DATASET_PARENTS = 256 # प्रत्येक डेटासेट घटकाच्या पॅरेंट्सची संख्या +CACHE_ROUNDS = 3 # कॅशे उत्पादनातील फेऱ्यांची संख्या +ACCESSES = 64 # हाशिमोटो लूपमधील प्रवेशांची संख्या +``` + +### 'SHA3' चा वापर {#sha3} + +Ethereum चा विकास SHA3 मानकाच्या विकासासोबतच झाला आणि मानकीकरण प्रक्रियेने अंतिम हॅश अल्गोरिदमच्या पॅडिंगमध्ये उशीरा बदल केला, त्यामुळे Ethereum चे "sha3_256" आणि "sha3_512" हॅश हे मानक sha3 हॅश नाहीत, तर एक प्रकार आहे ज्याला इतर संदर्भांमध्ये अनेकदा "Keccak-256" आणि "Keccak-512" असे संबोधले जाते. चर्चा पहा, उदा., [येथे](https://eips.ethereum.org/EIPS/eip-1803), [येथे](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), किंवा [येथे](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +कृपया हे लक्षात ठेवा कारण खालील अल्गोरिदमच्या वर्णनात "sha3" हॅशचा उल्लेख आहे. + +## मापदंड {#parameters} + +एथहॅशच्या कॅशे आणि डेटासेटसाठी पॅरामीटर्स ब्लॉक क्रमांकावर अवलंबून असतात. कॅशे आकार आणि डेटासेट आकार दोन्ही रेषीयपणे वाढतात; तथापि, चक्रीय वर्तणुकीला कारणीभूत होणाऱ्या अपघाती नियमिततेचा धोका कमी करण्यासाठी आम्ही नेहमी रेषीय वाढत्या थ्रेशोल्डच्या खाली सर्वोच्च अविभाज्य संख्या घेतो. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +डेटासेट आणि कॅशे आकाराच्या मूल्यांचे तक्ते परिशिष्टात दिले आहेत. + +## कॅशे निर्मिती {#cache-generation} + +आता, आम्ही कॅशे तयार करण्याचे कार्य निर्दिष्ट करतो: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # क्रमाने प्रारंभिक डेटासेट तयार करा + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # randmemohash ची कमी-फेरीची आवृत्ती वापरा + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +कॅशे उत्पादन प्रक्रियेत प्रथम क्रमाने ३२ MB मेमरी भरणे, नंतर सर्जियो डेमियन लर्नरच्या [_स्ट्रिक्ट मेमरी हार्ड हॅशिंग फंक्शन्स_ (२०१४)](http://www.hashcash.org/papers/memohash.pdf) मधील _RandMemoHash_ अल्गोरिदमच्या दोन फेऱ्या करणे समाविष्ट आहे. आउटपुट ५२४२८८ ६४-बाइट मूल्यांचा एक संच आहे. + +## डेटा एकत्रीकरण कार्य {#date-aggregation-function} + +आम्ही काही प्रकरणांमध्ये XOR साठी नॉन-असोसिएटिव्ह पर्याय म्हणून [FNV हॅश](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) द्वारे प्रेरित अल्गोरिदम वापरतो. लक्षात घ्या की आम्ही अविभाज्य संख्येला पूर्ण ३२-बिट इनपुटसह गुणतो, याउलट FNV-1 स्पेसिफिकेशन अविभाज्य संख्येला एका बाइट (ऑक्टेट) ने गुणते. + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +कृपया लक्षात घ्या, जरी यलो पेपरमध्ये fnv हे v1\*(FNV_PRIME ^ v2) म्हणून निर्दिष्ट केले असले तरी, सध्याची सर्व अंमलबजावणी सातत्याने वरील व्याख्या वापरतात. + +## पूर्ण डेटासेट गणना {#full-dataset-calculation} + +पूर्ण १ GB डेटासेटमधील प्रत्येक ६४-बाइट आयटम खालीलप्रमाणे मोजला जातो: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # मिक्स सुरू करा + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # i वर आधारित अनेक यादृच्छिक कॅशे नोड्ससह त्याचे fnv करा + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +मूलतः, आम्ही २५६ स्युडोरँडमली निवडलेल्या कॅशे नोड्समधील डेटा एकत्र करतो आणि डेटासेट नोडची गणना करण्यासाठी ते हॅश करतो. संपूर्ण डेटासेट नंतर याद्वारे तयार केला जातो: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## मुख्य लूप {#main-loop} + +आता, आम्ही मुख्य "हाशिमोटो" सारखी लूप निर्दिष्ट करतो, जिथे आम्ही विशिष्ट हेडर आणि नॉन्ससाठी आमचे अंतिम मूल्य तयार करण्यासाठी पूर्ण डेटासेटमधून डेटा एकत्र करतो. खालील कोडमध्ये, `header` हे एका _ट्रंकेटेड_ ब्लॉक हेडरच्या RLP प्रतिनिधित्वाचा SHA3-256 _हॅश_ दर्शविते, म्हणजेच, **mixHash** आणि **nonce** फील्ड वगळून एका हेडरचा. `nonce` हे बिग-एन्डियन क्रमाने ६४ बिट अनसाईन्ड इंटीजरचे आठ बाइट्स आहेत. त्यामुळे `nonce[::-1]` हे त्या मूल्याचे आठ-बाइट लिटिल-एन्डियन प्रतिनिधित्व आहे: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # हेडर+नॉन्स एकत्र करून ६४ बाइटचा सीड तयार करा + s = sha3_512(header + nonce[::-1]) + # प्रतिकृती केलेल्या s सह मिक्स सुरू करा + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # यादृच्छिक डेटासेट नोड्समध्ये मिक्स करा + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # मिक्स कॉम्प्रेस करा + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +मूलतः, आम्ही १२८ बाइट्स रुंद असलेला एक "मिक्स" राखतो आणि पूर्ण डेटासेटमधून वारंवार क्रमाने १२८ बाइट्स आणतो आणि ते मिक्ससह एकत्र करण्यासाठी `fnv` फंक्शन वापरतो. १२८ बाइट्सचा क्रमिक प्रवेश वापरला जातो जेणेकरून अल्गोरिदमची प्रत्येक फेरी नेहमी RAM मधून एक पूर्ण पृष्ठ आणेल, ज्यामुळे ट्रान्सलेशन लुकअसाइड बफर मिसेस कमी होतात जे ASICs सैद्धांतिकदृष्ट्या टाळू शकले असते. + +जर या अल्गोरिदमचे आउटपुट इच्छित लक्ष्यापेक्षा कमी असेल, तर नॉन्स वैध आहे. लक्षात घ्या की शेवटी `sha3_256` चा अतिरिक्त अनुप्रयोग हे सुनिश्चित करतो की एक मध्यवर्ती नॉन्स अस्तित्वात आहे जो किमान थोडे काम केले आहे हे सिद्ध करण्यासाठी प्रदान केला जाऊ शकतो; हे जलद बाह्य PoW सत्यापन अँटी-DDoS हेतूंसाठी वापरले जाऊ शकते. हे परिणाम एक निःपक्षपाती, २५६-बिट संख्या आहे याची सांख्यिकीय खात्री देण्याचे काम देखील करते. + +## मायनिंग {#mining} + +मायनिंग अल्गोरिदम खालीलप्रमाणे परिभाषित केला आहे: + +```python +def mine(full_size, dataset, header, difficulty): + # समान अंकावर हॅशशी तुलना करण्यासाठी टार्गेटला शून्य-पॅड करा + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## सीड हॅश परिभाषित करणे {#seed-hash} + +दिलेल्या ब्लॉकवर माइन करण्यासाठी वापरल्या जाणाऱ्या सीड हॅशची गणना करण्यासाठी, आम्ही खालील अल्गोरिदम वापरतो: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +लक्षात घ्या की सुरळीत मायनिंग आणि पडताळणीसाठी, आम्ही भविष्यातील सीडहॅश आणि डेटासेट एका वेगळ्या थ्रेडमध्ये पूर्व-गणना करण्याची शिफारस करतो. + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## परिशिष्ट {#appendix} + +जर तुम्हाला वरील पायथन स्पेसिफिकेशन कोड म्हणून चालवण्यात स्वारस्य असेल तर खालील कोड आधी जोडला पाहिजे. + +```python +import sha3, copy + +# लिट्ल एंडियन बिट ऑर्डरिंग गृहीत धरते (इंटेल आर्किटेक्चर्स प्रमाणेच) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# sha3 हॅश फंक्शन, ६४ बाइट्स आउटपुट देते +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### डेटा आकार {#data-sizes} + +खालील लुकअप टेबल अंदाजे २०४८ सारणीबद्ध इपॉक्ससाठी डेटा आकार आणि कॅशे आकार प्रदान करतात. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git a/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..7480fd91c85 --- /dev/null +++ b/public/content/translations/mr/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "मायनिंग अल्गोरिदम" +description: "Ethereum मायनिंगसाठी वापरलेल्या अल्गोरिदम्सबद्दल सविस्तर माहिती." +lang: mr +--- + + + + + +प्रूफ-ऑफ-वर्क आता Ethereum च्या एकमत यंत्रणेचा आधार नाही, याचा अर्थ मायनिंग बंद करण्यात आले आहे. त्याऐवजी, Ethereum ETH स्टेक करणाऱ्या व्हॅलिडेटर्सद्वारे सुरक्षित आहे. तुम्ही आजच तुमचे ETH स्टेक करणे सुरू करू शकता. द मर्ज, प्रूफ-ऑफ-स्टेक, आणि स्टेकिंग यावर अधिक वाचा. हे पान केवळ ऐतिहासिक माहितीसाठी आहे. + + + + +Ethereum मायनिंगमध्ये Ethash नावाचा अल्गोरिदम वापरला जात होता. अल्गोरिदमची मूळ कल्पना अशी आहे की, मायनर ब्रूट फोर्स कंप्युटेशन वापरून एक नॉन्स इनपुट शोधण्याचा प्रयत्न करतो, जेणेकरून मिळणारा हॅश हा कॅल्क्युलेटेड डिफिकल्टीनुसार ठरवलेल्या थ्रेशोल्डपेक्षा लहान असेल. ही डिफिकल्टी लेव्हल डायनॅमिकली ॲडजस्ट केली जाऊ शकते, ज्यामुळे नियमित अंतराने ब्लॉक तयार होऊ शकतात. + +## पूर्वतयारी {#prerequisites} + +हे पेज अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [प्रूफ-ऑफ-वर्क कन्सेन्सस](/developers/docs/consensus-mechanisms/pow) आणि [मायनिंग](/developers/docs/consensus-mechanisms/pow/mining) याबद्दल वाचा. + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto हा Ethereum मायनिंगसाठीचा एक पूर्ववर्ती संशोधन अल्गोरिदम होता, ज्याची जागा Ethash ने घेतली. हे दोन वेगवेगळ्या अल्गोरिदम्सचे एकत्रीकरण होते: Dagger आणि Hashimoto. हे केवळ एक संशोधन अंमलबजावणी होते आणि Ethereum मेननेट लाँच होईपर्यंत Ethash ने त्याची जागा घेतली होती. + +[Dagger](http://www.hashcash.org/papers/dagger.html) मध्ये [डायरेक्टेड एसायक्लिक ग्राफ](https://en.wikipedia.org/wiki/Directed_acyclic_graph) तयार करणे समाविष्ट आहे, ज्याचे रँडम स्लाइस एकत्र हॅश केले जातात. मूळ तत्त्व हे आहे की प्रत्येक नॉन्ससाठी मोठ्या डेटा ट्रीच्या फक्त एका लहान भागाची आवश्यकता असते. प्रत्येक नॉन्ससाठी सबट्रीची पुन्हा गणना करणे मायनिंगसाठी खूपच खर्चिक आहे - त्यामुळे ट्री संग्रहित करण्याची गरज आहे - परंतु एका नॉन्सच्या व्हेरिफिकेशनसाठी ते ठीक आहे. Dagger ची रचना Scrypt सारख्या विद्यमान अल्गोरिदम्सना पर्याय म्हणून केली गेली होती, जे मेमरी-हार्ड आहेत परंतु जेव्हा त्यांची मेमरी-हार्डनेस खरोखर सुरक्षित पातळीपर्यंत वाढते तेव्हा व्हेरिफाय करणे कठीण होते. तथापि, Dagger शेअर्ड मेमरी हार्डवेअर ॲक्सिलरेशनसाठी असुरक्षित होता आणि संशोधनाच्या इतर मार्गांसाठी तो वगळण्यात आला. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) हा एक अल्गोरिदम आहे जो I/O बाउंड (म्हणजे, मेमरी रीड्स ही मायनिंग प्रक्रियेतील मर्यादित घटक आहे) असल्यामुळे ASIC-प्रतिरोधक आहे. सिद्धांत असा आहे की कंप्युटेशनपेक्षा RAM अधिक उपलब्ध आहे; अब्जावधी डॉलर्सच्या संशोधनाने आधीच वेगवेगळ्या वापराच्या प्रकरणांसाठी RAM ऑप्टिमाइझ करण्यावर लक्ष केंद्रित केले आहे, ज्यात अनेकदा जवळपास-रँडम ॲक्सेस पॅटर्न (म्हणूनच “रँडम ॲक्सेस मेमरी”) समाविष्ट असतात. परिणामी, विद्यमान RAM अल्गोरिदमचे मूल्यांकन करण्यासाठी मध्यम प्रमाणात ऑप्टिमल असण्याची शक्यता आहे. Hashimoto डेटाचा स्रोत म्हणून ब्लॉकचेन वापरतो, आणि एकाच वेळी वरील (1) आणि (3) पूर्ण करतो. + +Dagger-Hashimoto मध्ये Dagger आणि Hashimoto अल्गोरिदम्सच्या सुधारित आवृत्त्या वापरल्या गेल्या. Dagger Hashimoto आणि Hashimoto मधील फरक हा आहे की, ब्लॉकचेनला डेटा स्रोत म्हणून वापरण्याऐवजी, Dagger Hashimoto कस्टम-जनरेटेड डेटा सेट वापरतो, जो प्रत्येक N ब्लॉक्सनंतर ब्लॉक डेटावर आधारित अपडेट होतो. हा डेटा सेट Dagger अल्गोरिदम वापरून तयार केला जातो, ज्यामुळे लाइट क्लायंट व्हेरिफिकेशन अल्गोरिदमसाठी प्रत्येक नॉन्ससाठी विशिष्ट सबसेटची कार्यक्षमतेने गणना करता येते. Dagger Hashimoto आणि Dagger मधील फरक हा आहे की, मूळ Dagger च्या विपरीत, ब्लॉकला क्वेरी करण्यासाठी वापरलेला डेटासेट अर्ध-स्थायी असतो, जो केवळ अधूनमधून (उदा., आठवड्यातून एकदा) अपडेट केला जातो. याचा अर्थ असा की डेटासेट तयार करण्याच्या प्रयत्नांचा भाग शून्याच्या जवळ आहे, त्यामुळे शेअर्ड मेमरी स्पीडअप्सबद्दल सर्जियो लर्नरचे युक्तिवाद नगण्य ठरतात. + +[Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) बद्दल अधिक माहिती. + +## Ethash {#ethash} + +Ethash हा मायनिंग अल्गोरिदम होता जो आता रद्द झालेल्या प्रूफ-ऑफ-वर्क आर्किटेक्चर अंतर्गत वास्तविक Ethereum मेननेटवर वापरला गेला होता. अल्गोरिदममध्ये लक्षणीय बदल झाल्यानंतर Dagger-Hashimoto च्या विशिष्ट आवृत्तीला Ethash हे नवीन नाव दिले गेले, तरीही त्याने आपल्या पूर्ववर्तीची मूलभूत तत्त्वे कायम ठेवली. Ethereum मेननेटने केवळ Ethash वापरला - Dagger Hashimoto हे मायनिंग अल्गोरिदमचे R&D आवृत्ती होते, जे Ethereum मेननेटवर मायनिंग सुरू होण्यापूर्वी बदलण्यात आले होते. + +[Ethash](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash) बद्दल अधिक माहिती. + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ diff --git a/public/content/translations/mr/developers/docs/dapps/index.md b/public/content/translations/mr/developers/docs/dapps/index.md new file mode 100644 index 00000000000..bf5785e9ad9 --- /dev/null +++ b/public/content/translations/mr/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "dapps ची तांत्रिक ओळख" +description: +lang: mr +--- + +विकेंद्रित ॲप्लिकेशन (dapp) हे एक विकेंद्रित नेटवर्कवर तयार केलेले ॲप्लिकेशन आहे जे [स्मार्ट कॉन्ट्रॅक्ट](/developers/docs/smart-contracts/) आणि फ्रंटएंड यूजर इंटरफेस एकत्र करते. Ethereum वर, स्मार्ट कॉन्ट्रॅक्ट्स प्रवेशयोग्य आणि पारदर्शक आहेत – खुल्या API प्रमाणे – त्यामुळे तुमच्या dapp मध्ये दुसऱ्या कोणीतरी लिहिलेले स्मार्ट कॉन्ट्रॅक्ट देखील समाविष्ट असू शकते. + +## पूर्वतयारी {#prerequisites} + +dapps बद्दल जाणून घेण्यापूर्वी, तुम्ही [ब्लॉकचेनची मूलभूत माहिती](/developers/docs/intro-to-ethereum/) घेतली पाहिजे आणि Ethereum नेटवर्क आणि ते कसे विकेंद्रित आहे याबद्दल वाचले पाहिजे. + +## dapp ची व्याख्या {#definition-of-a-dapp} + +dapp चा बॅकएंड कोड विकेंद्रित पीअर-टू-पीअर नेटवर्कवर चालतो. याची तुलना अशा ॲपशी करा जिथे बॅकएंड कोड केंद्रीकृत सर्व्हरवर चालत आहे. + +dapp मध्ये फ्रंटएंड कोड आणि यूजर इंटरफेस कोणत्याही भाषेत (ॲपप्रमाणेच) लिहिलेले असू शकतात जेणेकरून ते त्याच्या बॅकएंडला कॉल करू शकतील. शिवाय, त्याचा फ्रंटएंड [IPFS](https://ipfs.io/) सारख्या विकेंद्रित स्टोरेजवर होस्ट केला जाऊ शकतो. + +- **विकेंद्रित** - dapps Ethereum वर चालतात, जे एक खुले सार्वजनिक विकेंद्रित प्लॅटफॉर्म आहे जिथे कोणत्याही एका व्यक्तीचे किंवा गटाचे नियंत्रण नसते +- **निर्धारक** - dapps ज्या वातावरणात कार्यान्वित केले जातात त्याकडे दुर्लक्ष करून समान कार्य करतात +- **ट्युरिंग पूर्ण** - आवश्यक संसाधने दिल्यास dapps कोणतीही कृती करू शकतात +- **विलग** - dapps Ethereum व्हर्च्युअल मशीन म्हणून ओळखल्या जाणार्‍या व्हर्च्युअल वातावरणात कार्यान्वित केले जातात जेणेकरून स्मार्ट कॉन्ट्रॅक्टमध्ये बग असल्यास, ते ब्लॉकचेन नेटवर्कच्या सामान्य कामकाजात अडथळा आणणार नाही + +### स्मार्ट कॉन्ट्रॅक्ट्सवर {#on-smart-contracts} + +dapps ची ओळख करून देण्यासाठी, आम्हाला स्मार्ट कॉन्ट्रॅक्ट्सची ओळख करून देणे आवश्यक आहे – चांगल्या शब्दाच्या अभावी dapp चा बॅकएंड. तपशीलवार माहितीसाठी, आमच्या [स्मार्ट कॉन्ट्रॅक्ट्स](/developers/docs/smart-contracts/) वरील विभागाकडे जा. + +स्मार्ट कॉन्ट्रॅक्ट हा एक कोड आहे जो Ethereum ब्लॉकचेनवर राहतो आणि प्रोग्राम केल्याप्रमाणेच चालतो. एकदा स्मार्ट कॉन्ट्रॅक्ट नेटवर्कवर तैनात झाल्यावर तुम्ही ते बदलू शकत नाही. Dapps विकेंद्रित केले जाऊ शकतात कारण ते एखाद्या व्यक्ती किंवा कंपनीद्वारे नव्हे, तर कॉन्ट्रॅक्टमध्ये लिहिलेल्या लॉजिकद्वारे नियंत्रित केले जातात. याचा अर्थ असाही होतो की तुम्हाला तुमचे कॉन्ट्रॅक्ट्स अत्यंत काळजीपूर्वक डिझाइन करणे आणि त्यांची पूर्णपणे चाचणी करणे आवश्यक आहे. + +## dapp डेव्हलपमेंटचे फायदे {#benefits-of-dapp-development} + +- **शून्य डाउनटाइम** – एकदा स्मार्ट कॉन्ट्रॅक्ट ब्लॉकचेनवर तैनात झाल्यावर, संपूर्ण नेटवर्क नेहमीच कॉन्ट्रॅक्टशी संवाद साधू पाहणाऱ्या क्लायंटना सेवा देऊ शकेल. त्यामुळे, दुर्भावनापूर्ण घटक वैयक्तिक dapps वर लक्ष्यित डिनायल-ऑफ-सर्व्हिस हल्ले करू शकत नाहीत. +- **गोपनीयता** – dapp तैनात करण्यासाठी किंवा त्याच्याशी संवाद साधण्यासाठी तुम्हाला वास्तविक-जगातील ओळख प्रदान करण्याची आवश्यकता नाही. +- **सेन्सॉरशिपला प्रतिकार** – नेटवर्कवरील कोणतीही एकच संस्था वापरकर्त्यांना व्यवहार सबमिट करण्यापासून, dapps तैनात करण्यापासून किंवा ब्लॉकचेनमधून डेटा वाचण्यापासून रोखू शकत नाही. +- **संपूर्ण डेटा अखंडता** – क्रिप्टोग्राफिक प्रिमिटिव्हमुळे ब्लॉकचेनवर संग्रहित केलेला डेटा अपरिवर्तनीय आणि निर्विवाद आहे. दुर्भावनापूर्ण घटक आधीच सार्वजनिक केलेले व्यवहार किंवा इतर डेटा बनावट करू शकत नाहीत. +- **विश्वासहीन गणना/सत्यापन करण्यायोग्य वर्तन** – स्मार्ट कॉन्ट्रॅक्ट्सचे विश्लेषण केले जाऊ शकते आणि केंद्रीय प्राधिकरणावर विश्वास ठेवण्याची गरज न बाळगता ते अंदाजित मार्गांनी कार्यान्वित होण्याची हमी दिली जाते. हे पारंपारिक मॉडेल्समध्ये खरे नाही; उदाहरणार्थ, जेव्हा आपण ऑनलाइन बँकिंग प्रणाली वापरतो, तेव्हा आपल्याला विश्वास ठेवावा लागतो की वित्तीय संस्था आमच्या आर्थिक डेटाचा गैरवापर करणार नाहीत, रेकॉर्डमध्ये फेरफार करणार नाहीत किंवा हॅक होणार नाहीत. + +## dapp डेव्हलपमेंटचे तोटे {#drawbacks-of-dapp-development} + +- **देखभाल** – Dapps ची देखभाल करणे अधिक कठीण असू शकते कारण ब्लॉकचेनवर प्रकाशित केलेला कोड आणि डेटा सुधारणे कठीण आहे. डेव्हलपर्ससाठी एकदा तैनात केल्यावर त्यांच्या dapps मध्ये (किंवा dapp द्वारे संग्रहित केलेल्या मूळ डेटामध्ये) अद्यतने करणे कठीण आहे, जरी जुन्या आवृत्तीमध्ये बग किंवा सुरक्षा धोके ओळखले गेले तरीही. +- **कार्यप्रदर्शन ओव्हरहेड** – एक मोठा कार्यप्रदर्शन ओव्हरहेड आहे, आणि स्केलिंग खरोखर कठीण आहे. सुरक्षितता, अखंडता, पारदर्शकता आणि विश्वासार्हतेची पातळी गाठण्यासाठी ज्याची Ethereum आकांक्षा बाळगते, प्रत्येक नोड प्रत्येक व्यवहार चालवतो आणि संग्रहित करतो. यावर, प्रूफ-ऑफ-स्टेक सहमतीला देखील वेळ लागतो. +- **नेटवर्क गर्दी** – जेव्हा एक dapp खूप जास्त संगणकीय संसाधने वापरते, तेव्हा संपूर्ण नेटवर्क बॅक अप होते. सध्या, नेटवर्क प्रति सेकंद फक्त 10-15 व्यवहार प्रक्रिया करू शकते; जर व्यवहार यापेक्षा वेगाने पाठवले जात असतील, तर अपुष्ट व्यवहारांचा पूल पटकन फुगू शकतो. +- **वापरकर्ता अनुभव** – वापरकर्ता-अनुकूल अनुभव तयार करणे अधिक कठीण असू शकते कारण सरासरी अंतिम-वापरकर्त्याला खऱ्या अर्थाने सुरक्षित पद्धतीने ब्लॉकचेनशी संवाद साधण्यासाठी आवश्यक असलेले टूल स्टॅक सेट करणे खूप कठीण वाटू शकते. +- **केंद्रीकरण** – Ethereum च्या बेस लेअरवर तयार केलेले वापरकर्ता-अनुकूल आणि डेव्हलपर-अनुकूल सोल्यूशन्स शेवटी केंद्रीकृत सेवांसारखे दिसू शकतात. उदाहरणार्थ, अशा सेवा की (keys) किंवा इतर संवेदनशील माहिती सर्व्हर-साइडला संग्रहित करू शकतात, केंद्रीकृत सर्व्हर वापरून फ्रंटएंड सर्व्ह करू शकतात, किंवा ब्लॉकचेनवर लिहिण्यापूर्वी केंद्रीकृत सर्व्हरवर महत्त्वपूर्ण व्यावसायिक लॉजिक चालवू शकतात. केंद्रीकरण पारंपारिक मॉडेलपेक्षा ब्लॉकचेनचे अनेक (सर्व नाही तर) फायदे काढून टाकते. + +## तुम्ही पाहून शिकणारे आहात का? {#visual-learner} + + + +## dapps तयार करण्यासाठी साधने {#dapp-tools} + +**Scaffold-ETH _- तुमच्या स्मार्ट कॉन्ट्रॅक्टला अनुकूल असलेल्या फ्रंटएंडचा वापर करून Solidity सह पटकन प्रयोग करा._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [उदाहरण dapp](https://punkwallet.io/) + +**Create Eth App _- एका कमांडने Ethereum-सक्षम ॲप्स तयार करा._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- [ABI](/glossary/#abi) मधून dapp फ्रंटएंड्स तयार करण्यासाठी FOSS साधन._** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- Ethereum डेव्हलपर्ससाठी त्यांचे नोड तपासण्यासाठी आणि ब्राउझरमधून RPC कॉल्स तयार करण्यासाठी आणि डीबग करण्यासाठी FOSS साधन._** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- प्रत्येक भाषेत SDK, स्मार्ट कॉन्ट्रॅक्ट्स, साधने आणि web3 डेव्हलपमेंटसाठी पायाभूत सुविधा._** + +- [मुख्यपृष्ठ](https://thirdweb.com/) +- [दस्तऐवजीकरण](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- स्मार्ट कॉन्ट्रॅक्ट्स तैनात करण्यासाठी, क्रेडिट-कार्ड आणि क्रॉस चेन पेमेंट सक्षम करण्यासाठी, आणि NFTs तयार करण्यासाठी, वितरित करण्यासाठी, विकण्यासाठी, संग्रहित करण्यासाठी आणि संपादित करण्यासाठी API वापरण्यासाठी एंटरप्राइझ-ग्रेड web3 डेव्हलपमेंट प्लॅटफॉर्म._** + +- [crossmint.com](https://www.crossmint.com) +- [दस्तऐवजीकरण](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## पुढील वाचन {#further-reading} + +- [dapps एक्सप्लोर करा](/apps) +- [वेब 3.0 ॲप्लिकेशनची रचना](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _प्रीती कासिरेड्डी_ +- [विकेंद्रित ॲप्लिकेशन्ससाठी 2021 चे मार्गदर्शक](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [विकेंद्रित ॲप्स म्हणजे काय?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [लोकप्रिय dapps](https://www.alchemy.com/dapps) - _Alchemy_ + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## संबंधित विषय {#related-topics} + +- [Ethereum स्टॅकची ओळख](/developers/docs/ethereum-stack/) +- [डेव्हलपमेंट फ्रेमवर्क्स](/developers/docs/frameworks/) diff --git a/public/content/translations/mr/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/mr/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..d82be4f31af --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "ब्लॉक एक्सप्लोरर" +description: "ब्लॉक एक्सप्लोररची ओळख, ब्लॉकचेन डेटाच्या जगातील तुमचे पोर्टल, जिथे तुम्ही व्यवहार, खाती, करार आणि बरेच काही याबद्दल माहिती घेऊ शकता." +lang: mr +sidebarDepth: 3 +--- + +ब्लॉक एक्सप्लोरर हे Ethereumच्या डेटासाठी तुमचे पोर्टल आहेत. तुम्ही त्यांचा वापर ब्लॉक, व्यवहार, व्हॅलिडेटर्स, खाती आणि इतर ऑनचेन अ‍ॅक्टिव्हिटीवर रिअल-टाइम डेटा पाहण्यासाठी करू शकता. + +## पूर्वतयारी {#prerequisites} + +तुम्ही Ethereum च्या मूलभूत संकल्पना समजून घेतल्या पाहिजेत जेणेकरून तुम्हाला ब्लॉक एक्सप्लोररद्वारे दिलेल्या डेटाचा अर्थ लावता येईल. [Ethereum च्या परिचयाने](/developers/docs/intro-to-ethereum/) सुरुवात करा. + +## सेवा {#services} + +- [Etherscan](https://etherscan.io/) -_चीनी, कोरियन, रशियन आणि जपानी भाषेत देखील उपलब्ध आहे_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_स्पॅनिश, फ्रेंच, इटालियन, डच, पोर्तुगीज, रशियन, चीनी आणि फारसीमध्ये देखील उपलब्ध आहे_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru Block Explorer](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_चीनी, स्पॅनिश, फ्रेंच, तुर्की, रशियन, कोरियन आणि व्हिएतनामी भाषेत देखील उपलब्ध_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## ओपन सोर्स टूल्स {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## डेटा {#data} + +Ethereum डिझाइननुसार पारदर्शक आहे त्यामुळे सर्व काही सत्यापित करण्यायोग्य आहे. ब्लॉक एक्सप्लोरर ही माहिती मिळवण्यासाठी एक इंटरफेस प्रदान करतात. आणि हे मुख्य Ethereum नेटवर्क आणि टेस्टनेट दोन्हीसाठी आहे, जर तुम्हाला त्या डेटाची आवश्यकता असेल. डेटा एक्झिक्युशन डेटा आणि कन्सेन्सस डेटामध्ये विभागलेला आहे. एक्झिक्युशन डेटा एका विशिष्ट ब्लॉकमध्ये कार्यान्वित केलेल्या व्यवहारांना सूचित करतो. कन्सेन्सस डेटा स्वतः ब्लॉक आणि ज्या व्हॅलिडेटरनी ते प्रस्तावित केले आहेत त्यांना सूचित करतो. + +येथे डेटाच्या प्रकारांचा सारांश आहे जो तुम्ही ब्लॉक एक्सप्लोररकडून मिळवू शकता. + +### एक्झिक्युशन डेटा {#execution-data} + +दर 12 सेकंदांनी Ethereum मध्ये नवीन ब्लॉक जोडले जातात (जोपर्यंत ब्लॉक प्रस्तावक आपली पाळी चुकवत नाही), त्यामुळे ब्लॉक एक्सप्लोररमध्ये डेटाचा जवळपास-स्थिर प्रवाह जोडला जातो. ब्लॉकमध्ये भरपूर महत्त्वाची माहिती असते जी तुम्हाला उपयुक्त वाटू शकते: + +**मानक डेटा** + +- ब्लॉकची उंची - सध्याचा ब्लॉक तयार झाल्यावर ब्लॉक क्रमांक आणि ब्लॉकचेनची लांबी (ब्लॉकमध्ये) +- टाइमस्टॅम्प - ज्या वेळी ब्लॉक प्रस्तावित केला गेला होता +- व्यवहार - ब्लॉकमध्ये समाविष्ट असलेल्या व्यवहारांची संख्या +- शुल्क प्राप्तकर्ता - व्यवहारांमधून गॅस शुल्काच्या टिप्स प्राप्त करणारा पत्ता +- ब्लॉक रिवॉर्ड - ब्लॉक प्रस्तावित करणाऱ्या व्हॅलिडेटरला दिलेली ETH ची रक्कम +- आकार - ब्लॉकमधील डेटाचा आकार (बाईट्समध्ये मोजला जातो) +- वापरलेला गॅस - ब्लॉकमधील व्यवहारांद्वारे वापरलेल्या गॅसची एकूण युनिट्स +- गॅस मर्यादा - ब्लॉकमधील व्यवहारांद्वारे सेट केलेली एकूण गॅस मर्यादा +- प्रति गॅस मूळ शुल्क - ब्लॉकमध्ये व्यवहार समाविष्ट करण्यासाठी आवश्यक असलेला किमान गुणक +- जाळलेले शुल्क - ब्लॉकमध्ये किती ETH बर्न केले जाते +- अतिरिक्त डेटा - बिल्डरने ब्लॉकमध्ये समाविष्ट केलेला कोणताही अतिरिक्त डेटा + +**प्रगत डेटा** + +- हॅश - क्रिप्टोग्राफिक हॅश जो ब्लॉक हेडरचे प्रतिनिधित्व करतो (ब्लॉकचा युनिक आयडेंटिफायर) +- पॅरेंट हॅश - सध्याच्या ब्लॉकच्या आधी आलेल्या ब्लॉकचा हॅश +- स्टेट रूट - मर्केल ट्रायचा रूट हॅश जो सिस्टमची संपूर्ण स्थिती संग्रहित करतो + +### गॅस {#gas} + +ब्लॉक एक्सप्लोरर्स तुम्हाला केवळ व्यवहार आणि ब्लॉक्समधील गॅसच्या वापराबद्दल डेटा देणार नाहीत, तर काही तुम्हाला नेटवर्कच्या सध्याच्या गॅस किमतींबद्दल माहिती देतील. हे तुम्हाला नेटवर्क वापर समजण्यास, सुरक्षित व्यवहार सबमिट करण्यास आणि गॅसवर जास्त खर्च न करण्यास मदत करेल. अशा API शोधा जे तुम्हाला ही माहिती तुमच्या उत्पादनाच्या इंटरफेसमध्ये मिळविण्यात मदत करू शकतील. गॅस-विशिष्ट डेटामध्ये समाविष्ट आहे: + +- सुरक्षित परंतु हळू व्यवहारासाठी आवश्यक असलेल्या गॅसच्या अंदाजे युनिट्स (+ अंदाजे किंमत आणि कालावधी) +- सरासरी व्यवहारासाठी आवश्यक असलेल्या गॅसच्या अंदाजे युनिट्स (+ अंदाजे किंमत आणि कालावधी) +- जलद व्यवहारासाठी आवश्यक असलेल्या गॅसच्या अंदाजे युनिट्स (+ अंदाजे किंमत आणि कालावधी) +- गॅस किमतीवर आधारित सरासरी पुष्टीकरण वेळ +- गॅस वापरणारे करार - दुसऱ्या शब्दांत, लोकप्रिय उत्पादने जी नेटवर्कवर मोठ्या प्रमाणात वापरली जात आहेत +- गॅस खर्च करणारी खाती - दुसऱ्या शब्दांत, वारंवार नेटवर्क वापरणारे + +### व्यवहार {#transactions} + +लोकांना त्यांच्या व्यवहारांच्या प्रगतीचा मागोवा घेण्यासाठी ब्लॉक एक्सप्लोरर एक सामान्य जागा बनले आहेत. कारण तुम्हाला मिळणाऱ्या तपशिलाची पातळी अतिरिक्त निश्चितता प्रदान करते. व्यवहार डेटामध्ये समाविष्ट आहे: + +**मानक डेटा** + +- व्यवहार हॅश - व्यवहार सबमिट केल्यावर तयार केलेला हॅश +- स्थिती - व्यवहार प्रलंबित, अयशस्वी किंवा यशस्वी आहे की नाही याचे सूचक +- ब्लॉक - ज्या ब्लॉकमध्ये व्यवहार समाविष्ट केला गेला आहे +- टाइमस्टॅम्प - व्हॅलिडेटरने प्रस्तावित केलेल्या ब्लॉकमध्ये व्यवहार समाविष्ट करण्याची वेळ +- प्रेषक - व्यवहार सबमिट करणाऱ्या खात्याचा पत्ता +- प्राप्तकर्ता - प्राप्तकर्त्याचा किंवा स्मार्ट कराराचा पत्ता ज्याच्याशी व्यवहार संवाद साधतो +- हस्तांतरित केलेले टोकन - व्यवहाराचा भाग म्हणून हस्तांतरित केलेल्या टोकनची सूची +- मूल्य - हस्तांतरित केले जात असलेले एकूण ETH मूल्य +- व्यवहार शुल्क - व्यवहार प्रक्रिया करण्यासाठी व्हॅलिडेटरला दिलेली रक्कम (गॅसची किंमत \* वापरलेला गॅस द्वारे मोजली जाते) + +**प्रगत डेटा** + +- गॅस मर्यादा - हा व्यवहार वापरू शकणाऱ्या गॅस युनिट्सची कमाल संख्या +- वापरलेला गॅस - व्यवहाराने वापरलेल्या गॅस युनिट्सची वास्तविक रक्कम +- गॅसची किंमत - प्रति गॅस युनिट सेट केलेली किंमत +- नॉन्स - `from` पत्त्यासाठी व्यवहार क्रमांक (लक्षात ठेवा की हे 0 पासून सुरू होते त्यामुळे `100` चा नॉन्स प्रत्यक्षात या खात्याद्वारे सबमिट केलेला 101 वा व्यवहार असेल) +- इनपुट डेटा - व्यवहारासाठी आवश्यक असलेली कोणतीही अतिरिक्त माहिती + +### खाती {#accounts} + +खात्याबद्दल बरीच माहिती आहे जी तुम्ही ऍक्सेस करू शकता. म्हणूनच अनेक खाती वापरण्याची शिफारस केली जाते जेणेकरून तुमची मालमत्ता आणि मूल्य सहजपणे ट्रॅक केले जाऊ शकत नाही. व्यवहार आणि खात्यातील अ‍ॅक्टिव्हिटी अधिक खाजगी करण्यासाठी काही उपाययोजना देखील विकसित केल्या जात आहेत. परंतु येथे खात्यांसाठी उपलब्ध असलेला डेटा आहे: + +**वापरकर्ता खाती** + +- खात्याचा पत्ता - सार्वजनिक पत्ता ज्याचा वापर तुम्ही निधी पाठवण्यासाठी करू शकता +- ETH शिल्लक - त्या खात्याशी संबंधित ETH ची रक्कम +- एकूण ETH मूल्य - ETH चे मूल्य +- टोकन - खात्याशी संबंधित टोकन आणि त्यांचे मूल्य +- व्यवहाराचा इतिहास - सर्व व्यवहारांची सूची जिथे हे खाते प्रेषक किंवा प्राप्तकर्ता होते + +**स्मार्ट कॉन्ट्रॅक्ट** + +स्मार्ट कॉन्ट्रॅक्ट खात्यांमध्ये वापरकर्त्याच्या खात्यातील सर्व डेटा असतो, परंतु काही ब्लॉक एक्सप्लोरर काही कोड माहिती देखील प्रदर्शित करतील. उदाहरणांमध्ये समाविष्ट आहे: + +- करार निर्माता - मेननेटवर करार तैनात करणारा पत्ता +- निर्मिती व्यवहार - मेननेटवर तैनाती समाविष्ट असलेला व्यवहार +- स्रोत कोड - स्मार्ट कराराचा सॉलिडिटी किंवा वायपर कोड +- करार ABI - कराराचा ऍप्लिकेशन बायनरी इंटरफेस—करार करत असलेले कॉल आणि प्राप्त केलेला डेटा +- करार निर्मिती कोड - स्मार्ट कराराचा संकलित बायटेकोड—जेव्हा तुम्ही सॉलिडिटी किंवा वायपर इत्यादीमध्ये लिहिलेला स्मार्ट करार संकलित करता तेव्हा तयार होतो. +- करार इव्हेंट्स - स्मार्ट करारामध्ये कॉल केलेल्या पद्धतींचा इतिहास—मूलतः करार कसा वापरला जात आहे आणि किती वेळा हे पाहण्याचा एक मार्ग + +### टोकन {#tokens} + +टोकन हे एक प्रकारचे करार आहेत त्यामुळे त्यांच्याकडे स्मार्ट करारासारखाच डेटा असेल. परंतु त्यांचे मूल्य असल्यामुळे आणि त्यांचा व्यापार केला जाऊ शकत असल्यामुळे त्यांच्याकडे अतिरिक्त डेटा पॉइंट्स आहेत: + +- प्रकार - ते ERC-20, ERC-721 किंवा अन्य टोकन मानक आहेत की नाही +- किंमत - जर ते ERC-20 असतील तर त्यांचे सध्याचे बाजार मूल्य असेल +- बाजार भांडवल - जर ते ERC-20 असतील तर त्यांचे बाजार भांडवल असेल (किंमत \* एकूण पुरवठा द्वारे मोजले जाते) +- एकूण पुरवठा - चलनात असलेल्या टोकनची संख्या +- धारक - टोकन धारण करणाऱ्या पत्त्यांची संख्या +- हस्तांतरण - खात्यांदरम्यान टोकन किती वेळा हस्तांतरित केले गेले आहे +- व्यवहाराचा इतिहास - टोकनसह सर्व व्यवहारांचा इतिहास +- करार पत्ता - मेननेटवर तैनात केलेल्या टोकनचा पत्ता +- दशांश - ERC-20 टोकन विभाज्य आहेत आणि त्यात दशांश स्थळे आहेत + +### नेटवर्क {#network} + +काही ब्लॉक डेटा Ethereumच्या आरोग्याबद्दल अधिक समग्रपणे संबंधित आहे. + +- एकूण व्यवहार - Ethereum तयार झाल्यापासूनच्या व्यवहारांची संख्या +- प्रति सेकंद व्यवहार - एका सेकंदात प्रक्रिया करण्यायोग्य व्यवहारांची संख्या +- ETH किंमत - 1 ETH चे सध्याचे मूल्यांकन +- एकूण ETH पुरवठा - चलनात असलेल्या ETH ची संख्या—लक्षात ठेवा की प्रत्येक ब्लॉकच्या निर्मितीसह ब्लॉक रिवॉर्डच्या स्वरूपात नवीन ETH तयार केले जाते +- बाजार भांडवल - किंमत \* पुरवठा यांचे गणन + +## कन्सेन्सस लेयर डेटा {#consensus-layer-data} + +### इपॉक {#epoch} + +सुरक्षेच्या कारणास्तव, प्रत्येक इपॉकच्या शेवटी (प्रत्येक 6.4 मिनिटांनी) व्हॅलिडेटर्सच्या यादृच्छिक समित्या तयार केल्या जातात. इपॉक डेटामध्ये समाविष्ट आहे: + +- इपॉक क्रमांक +- अंतिम स्थिती - इपॉक अंतिम झाले आहे की नाही (होय/नाही) +- वेळ - इपॉक संपण्याची वेळ +- प्रमाणीकरण - इपॉकमधील प्रमाणीकरणांची संख्या (स्लॉट्समधील ब्लॉक्ससाठी मते) +- ठेवी - इपॉकमध्ये समाविष्ट असलेल्या ETH ठेवींची संख्या (व्हॅलिडेटर्सना व्हॅलिडेटर बनण्यासाठी ETH स्टेक करणे आवश्यक आहे) +- स्लॅशिंग - ब्लॉकच्या प्रस्तावक किंवा प्रमाणीकरण करणाऱ्यांना दिलेली दंडांची संख्या +- मतदान सहभाग - ब्लॉक्सना प्रमाणित करण्यासाठी वापरलेली स्टेक केलेली ETH ची रक्कम +- व्हॅलिडेटर्स - इपॉकसाठी सक्रिय असलेल्या व्हॅलिडेटर्सची संख्या +- सरासरी व्हॅलिडेटर शिल्लक - सक्रिय व्हॅलिडेटर्ससाठी सरासरी शिल्लक +- स्लॉट्स - इपॉकमध्ये समाविष्ट असलेल्या स्लॉट्सची संख्या (स्लॉट्समध्ये एक वैध ब्लॉक असतो) + +### स्लॉट {#slot} + +स्लॉट्स हे ब्लॉक निर्मितीच्या संधी आहेत, प्रत्येक स्लॉटसाठी उपलब्ध असलेल्या डेटामध्ये समाविष्ट आहे: + +- इपॉक - ज्या इपॉकमध्ये स्लॉट वैध आहे +- स्लॉट क्रमांक +- स्थिती - स्लॉटची स्थिती (प्रस्तावित/चुकलेला) +- वेळ - स्लॉट टाइमस्टॅम्प +- प्रस्तावक - स्लॉटसाठी ब्लॉक प्रस्तावित करणारा व्हॅलिडेटर +- ब्लॉक रूट - बीकनब्लॉकचा हॅश-ट्री-रूट +- पॅरेंट रूट - आधी आलेल्या ब्लॉकचा हॅश +- स्टेट रूट - बीकनस्टेटचा हॅश-ट्री-रूट +- सही +- Randao रिव्हील +- ग्राफिटी - एक ब्लॉक प्रस्तावक आपल्या ब्लॉक प्रस्तावात 32 बाइट लांबीचा संदेश समाविष्ट करू शकतो +- एक्झिक्युशन डेटा + - ब्लॉक हॅश + - ठेवींची संख्या + - ठेवींचा रूट +- प्रमाणीकरण - या स्लॉटमधील ब्लॉकसाठी प्रमाणीकरणांची संख्या +- ठेवी - या स्लॉट दरम्यानच्या ठेवींची संख्या +- स्वैच्छिक निर्गमन - स्लॉट दरम्यान बाहेर पडलेल्या व्हॅलिडेटर्सची संख्या +- स्लॅशिंग - ब्लॉकच्या प्रस्तावक किंवा प्रमाणीकरण करणाऱ्यांना दिलेली दंडांची संख्या +- मते - या स्लॉटमधील ब्लॉकसाठी मतदान करणारे व्हॅलिडेटर्स + +### ब्लॉक्स {#blocks-1} + +प्रूफ-ऑफ-स्टेक वेळेला स्लॉट्स आणि इपॉक्समध्ये विभाजित करतो. म्हणजे नवीन डेटा! + +- प्रस्तावक - नवीन ब्लॉक प्रस्तावित करण्यासाठी अल्गोरिदमद्वारे निवडलेला व्हॅलिडेटर +- इपॉक - ज्या इपॉकमध्ये ब्लॉक प्रस्तावित केला गेला होता +- स्लॉट - ज्या स्लॉटमध्ये ब्लॉक प्रस्तावित केला गेला होता +- प्रमाणीकरण - स्लॉटमध्ये समाविष्ट असलेल्या प्रमाणीकरणांची संख्या—प्रमाणीकरण मतांसारखे असतात जे सूचित करतात की ब्लॉक बीकन चेनवर जाण्यासाठी तयार आहे + +### व्हॅलिडेटर्स {#validators} + +व्हॅलिडेटर्स स्लॉट्समध्ये ब्लॉक प्रस्तावित करण्यासाठी आणि त्यांना प्रमाणित करण्यासाठी जबाबदार असतात. + +- व्हॅलिडेटर क्रमांक - व्हॅलिडेटरचे प्रतिनिधित्व करणारा युनिक क्रमांक +- सध्याची शिल्लक - व्हॅलिडेटरची बक्षिसांसह शिल्लक +- प्रभावी शिल्लक - व्हॅलिडेटरची शिल्लक जी स्टेक करण्यासाठी वापरली जाते +- उत्पन्न - व्हॅलिडेटरद्वारे प्राप्त बक्षिसे किंवा दंड +- स्थिती - व्हॅलिडेटर सध्या ऑनलाइन आणि सक्रिय आहे की नाही +- प्रमाणीकरण प्रभावीपणा - व्हॅलिडेटरच्या प्रमाणीकरणांना चेनमध्ये समाविष्ट करण्यासाठी लागणारा सरासरी वेळ +- सक्रियतेसाठी पात्रता - तारीख (आणि इपॉक) जेव्हा व्हॅलिडेटर प्रमाणित करण्यासाठी उपलब्ध झाला +- यापासून सक्रिय - तारीख (आणि इपॉक) जेव्हा व्हॅलिडेटर सक्रिय झाला +- प्रस्तावित ब्लॉक - व्हॅलिडेटरने प्रस्तावित केलेले ब्लॉक +- प्रमाणीकरण - व्हॅलिडेटरने प्रदान केलेले प्रमाणीकरण +- ठेवी - व्हॅलिडेटरने केलेल्या स्टेक केलेल्या ठेवीचा प्रेषक पत्ता, व्यवहार हॅश, ब्लॉक क्रमांक, टाइमस्टॅम्प, रक्कम आणि स्थिती + +### प्रमाणीकरण {#attestations} + +प्रमाणीकरण हे चेनमध्ये ब्लॉक समाविष्ट करण्यासाठी "होय" मते आहेत. त्यांचा डेटा प्रमाणीकरणाच्या रेकॉर्डशी आणि प्रमाणित करणाऱ्या व्हॅलिडेटर्सशी संबंधित आहे + +- स्लॉट - ज्या स्लॉटमध्ये प्रमाणीकरण झाले +- समिती निर्देशांक - दिलेल्या स्लॉटमधील समितीचा निर्देशांक +- एकत्रीकरण बिट्स - प्रमाणीकरणात सहभागी होणाऱ्या सर्व व्हॅलिडेटर्सच्या एकत्रित प्रमाणीकरणाचे प्रतिनिधित्व करते +- व्हॅलिडेटर्स - प्रमाणीकरण प्रदान करणारे व्हॅलिडेटर्स +- बीकन ब्लॉक रूट - व्हॅलिडेटर्स ज्या ब्लॉकला प्रमाणित करत आहेत त्याकडे निर्देश करतो +- स्रोत - नवीनतम न्याय्य इपॉककडे निर्देश करतो +- लक्ष्य - नवीनतम इपॉक सीमेकडे निर्देश करतो +- सही + +### नेटवर्क {#network-1} + +कन्सेन्सस लेयरच्या टॉप-लेव्हल डेटामध्ये खालील गोष्टींचा समावेश आहे: + +- सध्याचा इपॉक +- सध्याचा स्लॉट +- सक्रिय व्हॅलिडेटर्स - सक्रिय व्हॅलिडेटर्सची संख्या +- प्रलंबित व्हॅलिडेटर्स - सक्रिय होण्याची वाट पाहणाऱ्या व्हॅलिडेटर्सची संख्या +- स्टेक केलेले ETH - नेटवर्कमध्ये स्टेक केलेल्या ETH ची रक्कम +- सरासरी शिल्लक - व्हॅलिडेटर्सची सरासरी ETH शिल्लक + +## ब्लॉक एक्सप्लोरर्स {#block-explorers} + +- [Etherscan](https://etherscan.io/) - एक ब्लॉक एक्सप्लोरर ज्याचा वापर तुम्ही Ethereum मेननेट आणि टेस्टनेटसाठी डेटा आणण्यासाठी करू शकता +- [3xpl](https://3xpl.com/ethereum) - एक जाहिरात-मुक्त ओपन-सोर्स Ethereum एक्सप्लोरर जो त्याचे डेटासेट डाउनलोड करण्याची परवानगी देतो +- [Beaconcha.in](https://beaconcha.in/) - Ethereum मेननेट आणि टेस्टनेटसाठी एक ओपन सोर्स ब्लॉक एक्सप्लोरर +- [Blockchair](https://blockchair.com/ethereum) - सर्वात खाजगी Ethereum एक्सप्लोरर. डेटा (मेमपूल) वर्गीकरण आणि फिल्टरिंगसाठी देखील +- [Etherchain](https://www.etherchain.org/) - Ethereum मेननेटसाठी एक ब्लॉक एक्सप्लोरर +- [Ethplorer](https://ethplorer.io/) - Ethereum मेननेट आणि कोव्हान टेस्टनेटसाठी टोकनवर लक्ष केंद्रित करणारा ब्लॉक एक्सप्लोरर + +## पुढील वाचन {#further-reading} + +_तुम्हाला मदत केलेल्या सामुदायिक संसाधनाबद्दल माहिती आहे का?_ हे पृष्ठ संपादित करा आणि ते जोडा!_ + +## संबंधित विषय {#related-topics} + +- [व्यवहार](/developers/docs/transactions/) +- [खाती](/developers/docs/accounts/) +- [नेटवर्क्स](/developers/docs/networks/) diff --git a/public/content/translations/mr/developers/docs/data-and-analytics/index.md b/public/content/translations/mr/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..2d8911c0aff --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "माहिती आणि विश्लेषण" +description: "आपल्या dapps मध्ये वापरण्यासाठी ऑनचेन विश्लेषण आणि डेटा कसा मिळवायचा" +lang: mr +--- + +## परिचय {#Introduction} + +नेटवर्कचा वापर वाढत असताना, ऑनचेन डेटामध्ये मौल्यवान माहितीचे प्रमाण वाढत जाईल. डेटाचे प्रमाण वेगाने वाढत असताना, अहवाल देण्यासाठी किंवा dapp चालवण्यासाठी ही माहिती मोजणे आणि एकत्रित करणे हे वेळखाऊ आणि प्रक्रिया-जड प्रयत्न होऊ शकते. + +विद्यमान डेटा प्रदात्यांचा फायदा घेऊन विकास जलद होऊ शकतो, अधिक अचूक परिणाम मिळू शकतात, आणि चालू देखभालीचे प्रयत्न कमी होऊ शकतात. यामुळे संघाला त्यांच्या प्रकल्पाद्वारे प्रदान करण्याचा प्रयत्न करत असलेल्या मुख्य कार्यक्षमतेवर लक्ष केंद्रित करता येईल. + +## पूर्वतयारी {#prerequisites} + +डेटा विश्लेषण संदर्भात त्यांचा वापर अधिक चांगल्या प्रकारे समजून घेण्यासाठी आपण [ब्लॉक एक्सप्लोरर्स](/developers/docs/data-and-analytics/block-explorers/) ची मूलभूत संकल्पना समजून घेतली पाहिजे. याव्यतिरिक्त, सिस्टम डिझाइनमध्ये ते जोडत असलेले फायदे समजून घेण्यासाठी [इंडेक्स](/glossary/#index) च्या संकल्पनेशी स्वतःला परिचित करा. + +आर्किटेक्चरल मूलभूत तत्त्वांच्या बाबतीत, [API](https://www.wikipedia.org/wiki/API) आणि [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) काय आहेत हे सैद्धांतिकरित्या तरी समजून घेणे महत्त्वाचे आहे. + +## ब्लॉक एक्सप्लोरर्स {#block-explorers} + +अनेक [ब्लॉक एक्सप्लोरर्स](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) गेटवे देतात जे विकसकांना ब्लॉक्स, व्यवहार, व्हॅलिडेटर्स, खाती आणि इतर ऑनचेन क्रियाकलापांवरील रिअल-टाइम डेटामध्ये दृश्यमानता प्रदान करतील. + +विकसक नंतर हा डेटा प्रक्रिया आणि रूपांतरित करू शकतात जेणेकरून त्यांच्या वापरकर्त्यांना [ब्लॉकचेन](/glossary/#blockchain) सह अद्वितीय अंतर्दृष्टी आणि संवाद मिळू शकेल. उदाहरणार्थ, [Etherscan](https://etherscan.io) आणि [Blockscout](https://eth.blockscout.com) प्रत्येक १२ सेकंदांच्या स्लॉटसाठी अंमलबजावणी आणि सहमती डेटा प्रदान करतात. + +## द ग्राफ {#the-graph} + +[द ग्राफ](https://thegraph.com/) हा एक इंडेक्सिंग प्रोटोकॉल आहे जो सबग्राफ म्हणून ओळखल्या जाणाऱ्या ओपन API द्वारे ब्लॉकचेन डेटा क्वेरी करण्याचा एक सोपा मार्ग प्रदान करतो. + +द ग्राफसह, विकसकांना खालील फायदे मिळू शकतात: + +- विकेंद्रीकृत इंडेक्सिंग: एकाधिक इंडेक्सर्सद्वारे ब्लॉकचेन डेटा इंडेक्स करण्यास सक्षम करते, ज्यामुळे अपयशाचा कोणताही एक बिंदू दूर होतो +- GraphQL क्वेरीज: इंडेक्स केलेल्या डेटाची क्वेरी करण्यासाठी एक शक्तिशाली GraphQL इंटरफेस प्रदान करते, ज्यामुळे डेटा पुनर्प्राप्ती अत्यंत सोपी होते +- सानुकूलन: ब्लॉकचेन डेटा रूपांतरित करण्यासाठी आणि संग्रहित करण्यासाठी स्वतःचे तर्क परिभाषित करा आणि द ग्राफ नेटवर्कवरील इतर विकसकांनी प्रकाशित केलेले सबग्राफ पुन्हा वापरा + +५ मिनिटांत सबग्राफ तयार करण्यासाठी, उपयोजित करण्यासाठी आणि क्वेरी करण्यासाठी या [क्विक-स्टार्ट](https://thegraph.com/docs/en/quick-start/) मार्गदर्शकाचे अनुसरण करा. + +## क्लायंट विविधता {#client-diversity} + +[क्लायंट विविधता](/developers/docs/nodes-and-clients/client-diversity/) Ethereum नेटवर्कच्या एकूण आरोग्यासाठी महत्त्वाची आहे कारण ती बग्स आणि शोषणांपासून लवचिकता प्रदान करते. आता [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) आणि [Ethernodes](https://ethernodes.org/) यासह अनेक क्लायंट विविधता डॅशबोर्ड आहेत. + +## ड्युन अॅनालिटिक्स {#dune-analytics} + +[ड्युन अॅनालिटिक्स](https://dune.com/) ब्लॉकचेन डेटा रिलेशनल डेटाबेस (DuneSQL) टेबलमध्ये पूर्व-प्रक्रिया करते, वापरकर्त्यांना SQL वापरून ब्लॉकचेन डेटा क्वेरी करण्याची आणि क्वेरी परिणामांवर आधारित डॅशबोर्ड तयार करण्याची परवानगी देते. ऑनचेन डेटा ४ रॉ टेबलमध्ये आयोजित केला जातो: `blocks`, `transactions`, (इव्हेंट) `logs` आणि (कॉल) `traces`. लोकप्रिय करार आणि प्रोटोकॉल डीकोड केले गेले आहेत आणि प्रत्येकाकडे इव्हेंट आणि कॉल टेबलचा स्वतःचा संच आहे. त्या इव्हेंट आणि कॉल टेबलवर पुढे प्रक्रिया केली जाते आणि प्रोटोकॉलच्या प्रकारानुसार ॲबस्ट्रॅक्शन टेबलमध्ये आयोजित केले जाते, उदाहरणार्थ, dex, lending, stablecoins, इत्यादी. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) हे एक विकेंद्रित हायपर-स्केलेबल डेटा प्लॅटफॉर्म आहे जे मोठ्या प्रमाणात डेटामध्ये कार्यक्षम, परवानगीशिवाय प्रवेश प्रदान करण्यासाठी ऑप्टिमाइझ केलेले आहे. हे सध्या इव्हेंट लॉग, व्यवहार पावती, ट्रेस आणि प्रति-व्यवहार स्टेट डिफ्ससह ऐतिहासिक ऑन-चेन डेटा सेवा देते. SQD सानुकूल डेटा एक्सट्रॅक्शन आणि प्रोसेसिंग पाइपलाइन तयार करण्यासाठी एक शक्तिशाली टूलकिट प्रदान करते, प्रति सेकंद १५०k ब्लॉक्सपर्यंत इंडेक्सिंग गती प्राप्त करते. + +प्रारंभ करण्यासाठी, [दस्तऐवजीकरण](https://docs.sqd.dev/) ला भेट द्या किंवा आपण SQD सह काय तयार करू शकता याची [EVM उदाहरणे](https://github.com/subsquid-labs/squid-evm-examples) पहा. + +## SubQuery नेटवर्क {#subquery-network} + +[SubQuery](https://subquery.network/) एक अग्रगण्य डेटा इंडेक्सर आहे जो विकासकांना त्यांच्या web3 प्रकल्पांसाठी जलद, विश्वसनीय, विकेंद्रित आणि सानुकूलित API देतो. SubQuery १६५+ पेक्षा जास्त इकोसिस्टम (Ethereum सह) मधील विकासकांना त्यांच्या वापरकर्त्यांसाठी एक अंतर्ज्ञानी आणि विस्मयकारक अनुभव तयार करण्यासाठी समृद्ध इंडेक्स केलेल्या डेटासह सक्षम करते. SubQuery नेटवर्क आपल्या न थांबणाऱ्या ॲप्सला एका लवचिक आणि विकेंद्रित पायाभूत सुविधा नेटवर्कसह शक्ती देते. डेटा प्रोसेसिंग क्रियाकलापांसाठी सानुकूल बॅकएंड तयार करण्यात वेळ न घालवता, भविष्यातील web3 ॲप्लिकेशन्स तयार करण्यासाठी SubQuery च्या ब्लॉकचेन विकसक टूलकिटचा वापर करा. + +प्रारंभ करण्यासाठी, [SubQuery's managed service](https://managedservice.subquery.network/) किंवा [SubQuery's decentralised network](https://app.subquery.network/dashboard) वर थेट जाण्यापूर्वी चाचणीसाठी स्थानिक डॉकर वातावरणात मिनिटांत Ethereum ब्लॉकचेन डेटा इंडेक्स करणे सुरू करण्यासाठी [Ethereum क्विक स्टार्ट गाइड](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) ला भेट द्या. + +## EVM क्वेरी भाषा {#evm-query-language} + +EVM क्वेरी भाषा (EQL) ही एक SQL-सारखी भाषा आहे जी EVM (Ethereum Virtual Machine) चेन्सची क्वेरी करण्यासाठी डिझाइन केलेली आहे. EQL चे अंतिम उद्दिष्ट EVM चेनच्या फर्स्ट-क्लास सिटीझन्स (ब्लॉक्स, खाती आणि व्यवहार) वर जटिल रिलेशनल क्वेरींना समर्थन देणे आहे, त्याचवेळी विकसकांना आणि संशोधकांना दैनंदिन वापरासाठी अर्गोनॉमिक सिंटॅक्स प्रदान करणे. EQL सह, विकसक परिचित SQL-सारख्या सिंटॅक्सचा वापर करून ब्लॉकचेन डेटा मिळवू शकतात आणि जटिल बॉयलरप्लेट कोडची आवश्यकता दूर करू शकतात. EQL मानक ब्लॉकचेन डेटा विनंत्यांना (उदा. Ethereum वर खात्याचा नॉन्स आणि शिल्लक पुनर्प्राप्त करणे किंवा वर्तमान ब्लॉक आकार आणि टाइमस्टॅम्प मिळवणे) समर्थन देते आणि अधिक जटिल विनंत्या आणि वैशिष्ट्यांसाठी सतत समर्थन जोडत आहे. + +## अधिक वाचन {#further-reading} + +- [क्रिप्टो डेटाचे अन्वेषण I: डेटा फ्लो आर्किटेक्चर्स](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [ग्राफ नेटवर्क आढावा](https://thegraph.com/docs/en/about/) +- [ग्राफ क्वेरी प्लेग्राउंड](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [EtherScan वर API कोड उदाहरणे](https://etherscan.io/apis#contracts) +- [Blockscout वर API दस्तऐवजीकरण](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in बीकन चेन एक्सप्लोरर](https://beaconcha.in) +- [ड्युन बेसिक्स](https://docs.dune.com/#dune-basics) +- [SubQuery Ethereum क्विक स्टार्ट गाइड](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SQD नेटवर्क आढावा](https://docs.sqd.dev/) +- [EVM क्वेरी भाषा](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/mr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/mr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..cfed17621f5 --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "ब्लॉकचेन डेटा स्टोरेज धोरणे" +description: "ब्लॉकचेन वापरून डेटा साठवण्याचे अनेक मार्ग आहेत. हा लेख विविध धोरणे, त्यांचे खर्च आणि फायदे-तोटे, तसेच त्याचा सुरक्षितपणे वापर करण्यासाठीच्या आवश्यकतांची तुलना करेल." +lang: mr +--- + +ब्लॉकचेनवर थेट माहिती संग्रहित करण्याचे किंवा ब्लॉकचेनद्वारे सुरक्षित असलेल्या पद्धतीने माहिती संग्रहित करण्याचे अनेक मार्ग आहेत: + +- EIP-4844 ब्लॉब्स +- कॉलडेटा +- L1 यंत्रणांसह ऑफचेन +- कंत्राट "कोड" +- कार्यक्रम +- EVM स्टोरेज + +कोणती पद्धत वापरायची याची निवड अनेक निकषांवर आधारित आहे: + +- माहितीचा स्रोत. कॉलडेटामधील माहिती थेट ब्लॉकचेनमधून येऊ शकत नाही. +- माहितीचे अंतिम स्थान. कॉलडेटा केवळ त्या व्यवहारात उपलब्ध असतो ज्यामध्ये त्याचा समावेश असतो. इव्हेंट्स ऑनचेन अजिबात उपलब्ध नसतात. +- किती त्रास स्वीकारार्ह आहे? पूर्ण-प्रमाणातील नोड चालवणारे संगणक ब्राउझरमध्ये चालणाऱ्या अॅप्लिकेशनमधील लाइट क्लायंटपेक्षा जास्त प्रक्रिया करू शकतात. +- प्रत्येक नोडमधून माहिती सहज उपलब्ध करणे आवश्यक आहे का? +- सुरक्षेच्या आवश्यकता. + +## सुरक्षेच्या आवश्यकता {#security-requirements} + +सर्वसाधारणपणे, माहिती सुरक्षेमध्ये तीन गुणधर्म असतात: + +- _गोपनीयता_, अनधिकृत संस्थांना माहिती वाचण्याची परवानगी नाही. हे अनेक बाबतीत महत्त्वाचे आहे, परंतु येथे नाही. _ब्लॉकचेनवर कोणतीही गुपिते नाहीत_. ब्लॉकचेन्स काम करतात कारण कोणीही स्टेटमधील बदल सत्यापित करू शकतो, म्हणून त्यांचा थेट गुपिते साठवण्यासाठी वापर करणे अशक्य आहे. ब्लॉकचेनवर गोपनीय माहिती साठवण्याचे मार्ग आहेत, परंतु ते सर्व किमान एक की साठवण्यासाठी काही ऑफचेन घटकावर अवलंबून असतात. + +- _अखंडता_, माहिती अचूक आहे, ती अनधिकृत संस्थांद्वारे किंवा अनधिकृत मार्गांनी बदलली जाऊ शकत नाही (उदाहरणार्थ, `Transfer` इव्हेंटशिवाय [ERC-20 टोकन्स](https://eips.ethereum.org/EIPS/eip-20#events) हस्तांतरित करणे). ब्लॉकचेनवर, प्रत्येक नोड प्रत्येक स्टेट बदलाची पडताळणी करतो, ज्यामुळे अखंडता सुनिश्चित होते. + +- _उपलब्धता_, माहिती कोणत्याही अधिकृत संस्थेसाठी उपलब्ध आहे. ब्लॉकचेनवर, हे सामान्यतः प्रत्येक [पूर्ण नोड](https://ethereum.org/developers/docs/nodes-and-clients#full-node) वर माहिती उपलब्ध करून साधले जाते. + +येथील सर्व विविध उपायांमध्ये उत्कृष्ट अखंडता आहे, कारण हॅश L1 वर पोस्ट केले जातात. तथापि, त्यांच्याकडे वेगवेगळ्या उपलब्धतेची हमी आहे. + +## पूर्वतयारी {#prerequisites} + +तुम्हाला [ब्लॉकचेनच्या मूलभूत तत्त्वांची](/developers/docs/intro-to-ethereum/) चांगली समज असायला हवी. हे पृष्ठ असेही गृहीत धरते की वाचक [ब्लॉक्स](/developers/docs/blocks/), [व्यवहार](/developers/docs/transactions/) आणि इतर संबंधित विषयांबद्दल परिचित आहे. + +## EIP-4844 ब्लॉब्स {#eip-4844-blobs} + +[Dencun हार्डफोर्क](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) पासून, Ethereum ब्लॉकचेनमध्ये [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) समाविष्ट आहे, जे Ethereum मध्ये मर्यादित आयुष्य असलेले डेटा ब्लॉब्स जोडते (सुरुवातीला सुमारे [18 दिवस](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)). या ब्लॉब्सची किंमत [एक्झिक्यूशन गॅस](/developers/docs/gas) पासून वेगळी आहे, जरी त्यासाठी समान यंत्रणा वापरली जात असली तरी. ते तात्पुरता डेटा पोस्ट करण्याचा एक स्वस्त मार्ग आहेत. + +EIP-4844 ब्लॉब्सचा मुख्य उपयोग रोलअप्सना त्यांचे व्यवहार प्रकाशित करण्यासाठी आहे. [ऑप्टिमिस्टिक रोलअप्सना](/developers/docs/scaling/optimistic-rollups) त्यांच्या ब्लॉकचेनवर व्यवहार प्रकाशित करणे आवश्यक आहे. जर रोलअपच्या [सिक्वेन्सरने](https://docs.optimism.io/connect/resources/glossary#sequencer) चुकीचे स्टेट रूट पोस्ट केले तर [व्हॅलिडेटर्सना](https://docs.optimism.io/connect/resources/glossary#validator) चूक दुरुस्त करण्यास सक्षम करण्यासाठी ते व्यवहार [चॅलेंज कालावधीत](https://docs.optimism.io/connect/resources/glossary#challenge-period) कोणालाही उपलब्ध असणे आवश्यक आहे. + +तथापि, एकदा चॅलेंज कालावधी संपला आणि स्टेट रूट अंतिम झाले की, हे व्यवहार जाणून घेण्याचा उर्वरित उद्देश चेनच्या सद्य स्टेटची प्रतिकृती तयार करणे हा असतो. हे स्टेट चेन नोड्सवरून देखील उपलब्ध आहे, ज्यासाठी खूप कमी प्रक्रियेची आवश्यकता असते. म्हणून व्यवहाराची माहिती अजूनही काही ठिकाणी जतन केली पाहिजे, जसे की [ब्लॉक एक्सप्लोरर्स](/developers/docs/data-and-analytics/block-explorers), परंतु Ethereum द्वारे प्रदान केलेल्या सेन्सॉरशिप प्रतिरोधाच्या पातळीसाठी पैसे देण्याची गरज नाही. + +[झीरो-नॉलेज रोलअप्स](/developers/docs/scaling/zk-rollups/#data-availability) देखील इतर नोड्सना विद्यमान स्टेटची प्रतिकृती तयार करण्यास आणि व्हॅलिडिटी प्रूफ्स सत्यापित करण्यास सक्षम करण्यासाठी त्यांचा व्यवहार डेटा पोस्ट करतात, परंतु पुन्हा ही एक अल्प-मुदतीची आवश्यकता आहे. + +हे लिहित असताना, EIP-4844 वर पोस्ट करण्याचा खर्च प्रति बाइट एक wei (10-18 ETH) आहे, जो [ब्लॉब्स पोस्ट करणाऱ्या व्यवहारासह कोणत्याही व्यवहाराला लागणाऱ्या 21,000 एक्झिक्यूशन गॅसच्या](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) तुलनेत नगण्य आहे. तुम्ही [blobscan.com](https://blobscan.com/blocks) वर सध्याची EIP-4844 किंमत पाहू शकता. + +काही प्रसिद्ध रोलअप्सद्वारे पोस्ट केलेले ब्लॉब्स पाहण्यासाठी येथे अ‍ॅड्रेस दिले आहेत. + +| रोलअप | मेलबॉक्स अ‍ॅड्रेस | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## कॉलडेटा {#calldata} + +कॉलडेटा म्हणजे व्यवहाराचा भाग म्हणून पाठवलेले बाइट्स. हे ब्लॉकचेनच्या कायमस्वरूपी रेकॉर्डचा एक भाग म्हणून त्या व्यवहाराचा समावेश असलेल्या ब्लॉकमध्ये संग्रहित केले जाते. + +ब्लॉकचेनमध्ये कायमस्वरूपी डेटा टाकण्याची ही सर्वात स्वस्त पद्धत आहे. प्रति बाइट खर्च 4 एक्झिक्यूशन गॅस (जर बाइट शून्य असेल) किंवा 16 गॅस (इतर कोणतेही मूल्य) आहे. जर डेटा संकुचित केला असेल, जी एक मानक पद्धत आहे, तर प्रत्येक बाइट मूल्याची शक्यता समान असते, त्यामुळे सरासरी खर्च प्रति बाइट अंदाजे 15.95 गॅस येतो. + +हे लिहित असताना, किमती 12 gwei/gas आणि 2300 $/ETH आहेत, याचा अर्थ खर्च प्रति किलोबाइट अंदाजे 45 सेंट आहे. कारण EIP-4844 पूर्वी ही सर्वात स्वस्त पद्धत होती, हीच पद्धत रोलअप्सनी व्यवहार माहिती साठवण्यासाठी वापरली होती, जी [फॉल्ट चॅलेंजेससाठी](https://docs.optimism.io/stack/protocol/overview#fault-proofs) उपलब्ध असणे आवश्यक आहे, परंतु ती थेट ऑनचेन उपलब्ध असणे आवश्यक नाही. + +काही प्रसिद्ध रोलअप्सद्वारे पोस्ट केलेले व्यवहार पाहण्यासाठी येथे अ‍ॅड्रेस दिले आहेत. + +| रोलअप | मेलबॉक्स अ‍ॅड्रेस | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## L1 यंत्रणांसह ऑफचेन {#offchain-with-l1-mechs} + +तुमच्या सुरक्षेतील फायदे-तोट्यांवर अवलंबून, माहिती इतरत्र ठेवणे आणि आवश्यकतेनुसार डेटा उपलब्ध असल्याची खात्री करणारी यंत्रणा वापरणे स्वीकारार्ह असू शकते. हे काम करण्यासाठी दोन आवश्यकता आहेत: + +1. डेटाचा एक [हॅश](https://en.wikipedia.org/wiki/Cryptographic_hash_function) ब्लॉकचेनवर पोस्ट करा, ज्याला _इनपुट कमिटमेंट_ म्हणतात. हा एकच 32-बाइट शब्द असू शकतो, त्यामुळे तो महाग नाही. जोपर्यंत इनपुट कमिटमेंट उपलब्ध आहे, तोपर्यंत अखंडतेची खात्री असते कारण समान मूल्यावर हॅश होणारा कोणताही अन्य डेटा शोधणे व्यवहार्य नाही. त्यामुळे जर चुकीचा डेटा प्रदान केला गेला, तर तो ओळखला जाऊ शकतो. + +2. उपलब्धतेची खात्री देणारी यंत्रणा असावी. उदाहरणार्थ, [Redstone](https://redstone.xyz/docs/what-is-redstone) मध्ये कोणताही नोड उपलब्धता चॅलेंज सादर करू शकतो. जर सिक्वेन्सरने अंतिम मुदतीपर्यंत ऑनचेन प्रतिसाद दिला नाही, तर इनपुट कमिटमेंट टाकून दिली जाते, त्यामुळे माहिती कधीही पोस्ट केली गेली नव्हती असे मानले जाते. + +हे ऑप्टिमिस्टिक रोलअपसाठी स्वीकारार्ह आहे कारण आपण आधीच स्टेट रूटसाठी किमान एका प्रामाणिक व्हेरिफायरवर अवलंबून आहोत. असा प्रामाणिक व्हेरिफायर ब्लॉक्सवर प्रक्रिया करण्यासाठी त्याच्याकडे डेटा असल्याची खात्री करेल, आणि जर माहिती ऑफचेन उपलब्ध नसेल तर उपलब्धता चॅलेंज जारी करेल. या प्रकारच्या ऑप्टिमिस्टिक रोलअपला [प्लाझ्मा](/developers/docs/scaling/plasma/) म्हणतात. + +## कंत्राट कोड {#contract-code} + +जी माहिती एकदाच लिहिण्याची आवश्यकता आहे, जी कधीही ओव्हरराइट होत नाही आणि ऑनचेन उपलब्ध असणे आवश्यक आहे, ती कंत्राट कोड म्हणून संग्रहित केली जाऊ शकते. याचा अर्थ असा की आपण डेटासह एक "स्मार्ट कंत्राट" तयार करतो आणि नंतर माहिती वाचण्यासाठी [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) वापरतो. फायदा असा आहे की कोड कॉपी करणे तुलनेने स्वस्त आहे. + +मेमरी विस्ताराच्या खर्चाव्यतिरिक्त, `EXTCODECOPY` साठी कंत्राटाच्या पहिल्या प्रवेशासाठी (जेव्हा ते "कोल्ड" असते) 2600 गॅस खर्च येतो आणि त्याच कंत्राटातून त्यानंतरच्या प्रतींसाठी 100 गॅस अधिक प्रति 32 बाइट शब्दासाठी 3 गॅस खर्च येतो. कॉलडेटाच्या तुलनेत, ज्याचा खर्च प्रति बाइट 15.95 आहे, हे सुमारे 200 बाइट्सपासून स्वस्त आहे. [मेमरी विस्ताराच्या खर्चाच्या सूत्रानुसार](https://www.evm.codes/about#memoryexpansion), जोपर्यंत तुम्हाला 4MB पेक्षा जास्त मेमरीची आवश्यकता नाही, तोपर्यंत मेमरी विस्ताराचा खर्च कॉलडेटा जोडण्याच्या खर्चापेक्षा कमी आहे. + +अर्थात, हा फक्त डेटा _वाचण्याचा_ खर्च आहे. कंत्राट तयार करण्यासाठी अंदाजे 32,000 गॅस + 200 गॅस/बाइट खर्च येतो. जेव्हा समान माहिती वेगवेगळ्या व्यवहारांमध्ये अनेक वेळा वाचण्याची आवश्यकता असते तेव्हाच ही पद्धत किफायतशीर असते. + +कंत्राट कोड निरर्थक असू शकतो, जोपर्यंत तो `0xEF` ने सुरू होत नाही. `0xEF` ने सुरू होणारे कंत्राट [ethereum ऑब्जेक्ट फॉरमॅट](https://notes.ethereum.org/@ipsilon/evm-object-format-overview) म्हणून अर्थ लावले जातात, ज्यामध्ये अधिक कठोर आवश्यकता आहेत. + +## इव्हेंट्स {#events} + +[इव्हेंट्स](https://docs.alchemy.com/docs/solidity-events) स्मार्ट कंत्राटांद्वारे उत्सर्जित केले जातात, आणि ऑफचेन सॉफ्टवेअरद्वारे वाचले जातात. +त्यांचा फायदा असा आहे की ऑफचेन कोड इव्हेंट्स ऐकू शकतो. खर्च [गॅस](https://www.evm.codes/#a0?fork=cancun), 375 अधिक डेटाच्या प्रति बाइट 8 गॅस आहे. 12 gwei/gas आणि 2300 $/ETH वर, याचा अर्थ एक सेंट अधिक प्रति किलोबाइट 22 सेंट असा होतो. + +## स्टोरेज {#storage} + +स्मार्ट कंत्राटांना [कायमस्वरूपी स्टोरेज](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory)मध्ये प्रवेश असतो. तथापि, ते खूप महाग आहे. पूर्वी रिकाम्या असलेल्या स्टोरेज स्लॉटमध्ये 32 बाइटचा शब्द लिहिण्यासाठी [22,100 गॅस खर्च](https://www.evm.codes/#55?fork=cancun) येऊ शकतो. 12 gwei/gas आणि 2300 $/ETH वर, हे प्रति लेखन ऑपरेशन सुमारे 61 सेंट किंवा प्रति किलोबाइट $19.5 आहे. + +हे Ethereum मधील स्टोरेजचे सर्वात महाग स्वरूप आहे. + +## सारांश {#summary} + +ही सारणी विविध पर्याय, त्यांचे फायदे आणि तोटे यांचा सारांश देते. + +| स्टोरेजचा प्रकार | डेटाचा स्रोत | उपलब्धतेची हमी | ऑनचेन उपलब्धता | अतिरिक्त मर्यादा | +| ------------------- | ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------------------------------------ | +| EIP-4844 ब्लॉब्स | ऑफचेन | [~18 दिवसांसाठी](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) Ethereum हमी | फक्त हॅश उपलब्ध आहे | | +| कॉलडेटा | ऑफचेन | कायमस्वरूपी Ethereum हमी (ब्लॉकचेनचा भाग) | फक्त कंत्राटात लिहिले असेल तर आणि त्या व्यवहारात उपलब्ध | | +| L1 यंत्रणांसह ऑफचेन | ऑफचेन | चॅलेंज कालावधीत "एक प्रामाणिक व्हेरिफायर" हमी | फक्त हॅश | चॅलेंज यंत्रणेद्वारे हमी, फक्त चॅलेंज कालावधीत | +| कंत्राट कोड | ऑनचेन किंवा ऑफचेन | कायमस्वरूपी Ethereum हमी (ब्लॉकचेनचा भाग) | होय | "यादृच्छिक" अ‍ॅड्रेसवर लिहिलेले, `0xEF` ने सुरू होऊ शकत नाही | +| कार्यक्रम | ऑनचेन | कायमस्वरूपी Ethereum हमी (ब्लॉकचेनचा भाग) | नाही | | +| स्टोरेज | ऑनचेन | कायमस्वरूपी Ethereum हमी (ब्लॉकचेनचा भाग आणि ओव्हरराइट होईपर्यंत सद्य स्टेट) | होय | | diff --git a/public/content/translations/mr/developers/docs/data-availability/index.md b/public/content/translations/mr/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..3476018b98f --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "डेटा उपलब्धता" +description: "Ethereum मध्ये डेटा उपलब्धतेशी संबंधित समस्या आणि उपायांचे एक अवलोकन" +lang: mr +--- + +"विश्वास ठेवू नका, सत्यापित करा" हे Ethereum मधील एक सामान्य सूत्र आहे. यामागील कल्पना अशी आहे की तुमचा नोड त्याला पिअर्सकडून मिळालेल्या ब्लॉक्समधील सर्व व्यवहारांची अंमलबजावणी करून स्वतंत्रपणे मिळालेली माहिती योग्य आहे की नाही हे सत्यापित करू शकतो, जेणेकरून प्रस्तावित बदल नोडद्वारे स्वतंत्रपणे गणन केलेल्या बदलांशी तंतोतंत जुळतील याची खात्री करता येईल. याचा अर्थ असा की नोड्सना ब्लॉकच्या प्रेषकांवर प्रामाणिक असल्याचा विश्वास ठेवण्याची गरज नाही. डेटा गहाळ असल्यास हे शक्य नाही. + +**डेटा उपलब्धता** म्हणजे ब्लॉक सत्यापित करण्यासाठी आवश्यक असलेला डेटा नेटवर्कमधील सर्व सहभागींना खरोखर उपलब्ध आहे यावर वापरकर्त्याचा विश्वास. Ethereum लेयर 1 वरील फुल नोड्ससाठी हे तुलनेने सोपे आहे; फुल नोड प्रत्येक ब्लॉकमधील सर्व डेटाची एक प्रत डाउनलोड करतो - डाउनलोड करणे शक्य होण्यासाठी डेटा उपलब्ध _असलाच_ पाहिजे. गहाळ डेटा असलेला ब्लॉक ब्लॉकचेनमध्ये जोडण्याऐवजी टाकून दिला जातो. ही "ऑनचेन डेटा उपलब्धता" आहे आणि हे मोनोलिथिक ब्लॉकचेन्सचे वैशिष्ट्य आहे. फुल नोड्सना अवैध व्यवहार स्वीकारण्यासाठी फसवले जाऊ शकत नाही कारण ते प्रत्येक व्यवहार स्वतःसाठी डाउनलोड करतात आणि कार्यान्वित करतात. तथापि, मॉड्यूलर ब्लॉकचेन, लेयर 2 रोलअप आणि लाईट क्लायंटसाठी, डेटा उपलब्धतेचे परिदृश्य अधिक गुंतागुंतीचे आहे, ज्यासाठी काही अधिक अत्याधुनिक सत्यापन प्रक्रियांची आवश्यकता आहे. + +## पूर्वतयारी {#prerequisites} + +तुम्हाला [ब्लॉकचेनची मूलभूत तत्त्वे](/developers/docs/intro-to-ethereum/), विशेषतः [सहमती यंत्रणा](/developers/docs/consensus-mechanisms/) यांची चांगली समज असली पाहिजे. हे पृष्ठ असेही गृहीत धरते की वाचक [ब्लॉक्स](/developers/docs/blocks/), [व्यवहार](/developers/docs/transactions/), [नोड्स](/developers/docs/nodes-and-clients/), [स्केलिंग सोल्यूशन्स](/developers/docs/scaling/), आणि इतर संबंधित विषयांबद्दल परिचित आहेत. + +## डेटा उपलब्धता समस्या {#the-data-availability-problem} + +डेटा उपलब्धता समस्या म्हणजे, ब्लॉकचेनमध्ये जोडल्या जाणाऱ्या काही व्यवहार डेटाचे संक्षिप्त स्वरूप खरोखरच वैध व्यवहारांच्या संचाचे प्रतिनिधित्व करते हे संपूर्ण नेटवर्कला सिद्ध करण्याची गरज, पण असे करताना सर्व नोड्सना सर्व डेटा डाउनलोड करण्याची आवश्यकता न ठेवणे. स्वतंत्रपणे ब्लॉक्सची पडताळणी करण्यासाठी पूर्ण व्यवहार डेटा आवश्यक आहे, परंतु सर्व नोड्सना सर्व व्यवहार डेटा डाउनलोड करण्याची आवश्यकता असणे हे स्केलिंगसाठी एक अडथळा आहे. डेटा उपलब्धता समस्येवरील उपायांचे उद्दिष्ट नेटवर्कमधील अशा सहभागींना पुरेसे आश्वासन देणे आहे जे स्वतःसाठी डेटा डाउनलोड आणि संग्रहित करत नाहीत, की पूर्ण व्यवहार डेटा पडताळणीसाठी उपलब्ध करून देण्यात आला होता. + +[लाईट नोड्स](/developers/docs/nodes-and-clients/light-clients) आणि [लेयर 2 रोलअप्स](/developers/docs/scaling) ही नेटवर्कमधील अशा सहभागींची महत्त्वाची उदाहरणे आहेत ज्यांना डेटा उपलब्धतेची मजबूत हमी आवश्यक आहे परंतु ते स्वतःसाठी व्यवहार डेटा डाउनलोड आणि त्यावर प्रक्रिया करू शकत नाहीत. व्यवहार डेटा डाउनलोड करणे टाळल्यामुळेच लाईट नोड्स 'लाईट' (हलके) बनतात आणि रोलअप्सना प्रभावी स्केलिंग सोल्यूशन्स बनण्यास मदत होते. + +भविष्यातील ["स्टेटलेस"](/roadmap/statelessness) Ethereum क्लायंटसाठी डेटा उपलब्धता ही एक गंभीर चिंतेची बाब आहे, ज्यांना ब्लॉक्सची पडताळणी करण्यासाठी स्टेट डेटा डाउनलोड आणि संग्रहित करण्याची आवश्यकता नाही. स्टेटलेस क्लायंट्सना अजूनही खात्री असणे आवश्यक आहे की डेटा _कुठेतरी_ उपलब्ध आहे आणि त्यावर योग्यरित्या प्रक्रिया केली गेली आहे. + +## डेटा उपलब्धता उपाय {#data-availability-solutions} + +### डेटा उपलब्धता सॅम्पलिंग (DAS) {#data-availability-sampling} + +डेटा उपलब्धता सॅम्पलिंग (DAS) हा नेटवर्कसाठी कोणत्याही एका नोडवर जास्त ताण न टाकता डेटा उपलब्ध आहे की नाही हे तपासण्याचा एक मार्ग आहे. प्रत्येक नोड (नॉन-स्टेकिंग नोड्ससह) एकूण डेटाचा एक छोटा, यादृच्छिकपणे निवडलेला उपसंच डाउनलोड करतो. नमुने यशस्वीरित्या डाउनलोड केल्याने सर्व डेटा उपलब्ध असल्याची उच्च आत्मविश्वासाने पुष्टी होते. हे डेटा इरेजर कोडिंगवर अवलंबून आहे, जे रिडंडंट माहितीसह दिलेल्या डेटासेटचा विस्तार करते (हे करण्याचा मार्ग म्हणजे डेटावर _पॉलीनोमियल_ म्हणून ओळखले जाणारे फंक्शन फिट करणे आणि अतिरिक्त पॉईंट्सवर त्या पॉलीनोमियलचे मूल्यांकन करणे). हे आवश्यकतेनुसार रिडंडंट डेटामधून मूळ डेटा पुनर्प्राप्त करण्यास अनुमती देते. या डेटा निर्मितीचा परिणाम असा आहे की जर मूळ डेटाचा _कोणताही_ भाग अनुपलब्ध असेल, तर विस्तारित डेटाचा _अर्धा_ भाग गहाळ होईल! प्रत्येक नोडद्वारे डाउनलोड केलेल्या डेटा नमुन्यांचे प्रमाण अशा प्रकारे ट्यून केले जाऊ शकते की जर अर्ध्यापेक्षा कमी डेटा खरोखर उपलब्ध असेल, तर प्रत्येक क्लायंटद्वारे नमुना घेतलेल्या डेटाच्या तुकड्यांपैकी किमान एक तुकडा गहाळ असण्याची _अत्यंत_ शक्यता असते. + +[फुल डँकशार्डिंग](/roadmap/danksharding/#what-is-danksharding) लागू झाल्यानंतर रोलअप ऑपरेटर आपला व्यवहार डेटा उपलब्ध करतात याची खात्री करण्यासाठी DAS चा वापर केला जाईल. सर्व डेटा अस्तित्वात आहे याची खात्री करण्यासाठी Ethereum नोड्स वर स्पष्ट केलेल्या रिडंडंसी स्कीमचा वापर करून ब्लॉब्समध्ये प्रदान केलेल्या व्यवहार डेटाचे यादृच्छिकपणे सॅम्पल घेतील. ब्लॉक प्रोड्युसर्स लाईट क्लायंट्सना सुरक्षित ठेवण्यासाठी आपला सर्व डेटा उपलब्ध करून देत आहेत याची खात्री करण्यासाठी हीच पद्धत वापरली जाऊ शकते. त्याचप्रमाणे, [प्रस्तावक-निर्माता पृथक्करण (proposer-builder separation)](/roadmap/pbs) अंतर्गत, केवळ ब्लॉक बिल्डरलाच संपूर्ण ब्लॉकवर प्रक्रिया करणे आवश्यक असेल - इतर व्हॅलिडेटर्स डेटा उपलब्धता सॅम्पलिंग वापरून पडताळणी करतील. + +### डेटा उपलब्धता समित्या {#data-availability-committees} + +डेटा उपलब्धता समित्या (DACs) या विश्वसनीय पक्ष आहेत जे डेटा उपलब्धतेची हमी देतात किंवा त्याची साक्ष देतात. DACs चा वापर DAS च्या ऐवजी [किंवा त्याच्या संयोगाने](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) केला जाऊ शकतो. समित्यांसोबत येणारी सुरक्षा हमी विशिष्ट सेटअपवर अवलंबून असते. उदाहरणार्थ, लाईट नोड्ससाठी डेटा उपलब्धतेची साक्ष देण्यासाठी Ethereum व्हॅलिडेटर्सच्या यादृच्छिकपणे निवडलेल्या उपसंचांचा वापर करते. + +काही व्हॅलिडियम्सद्वारे DACs चा वापर केला जातो. DAC हा नोड्सचा एक विश्वसनीय संच आहे जो डेटाच्या प्रती ऑफलाइन संग्रहित करतो. विवादाच्या प्रसंगी डेटा उपलब्ध करून देणे DAC ला आवश्यक आहे. DAC चे सदस्य ऑनचेन साक्षांकन देखील प्रकाशित करतात हे सिद्ध करण्यासाठी की सदर डेटा खरोखर उपलब्ध आहे. काही व्हॅलिडियम्स DACs च्या जागी प्रूफ-ऑफ-स्टेक (PoS) व्हॅलिडेटर प्रणाली वापरतात. येथे, कोणीही व्हॅलिडेटर बनू शकतो आणि डेटा ऑफचेन संग्रहित करू शकतो. तथापि, त्यांना एक "बॉन्ड" प्रदान करणे आवश्यक आहे, जो स्मार्ट कॉन्ट्रॅक्टमध्ये जमा केला जातो. दुर्भावनापूर्ण वर्तनाच्या प्रसंगी, जसे की व्हॅलिडेटरने डेटा रोखून ठेवल्यास, बॉन्ड स्लॅश केला जाऊ शकतो. प्रूफ-ऑफ-स्टेक डेटा उपलब्धता समित्या नियमित DACs पेक्षा अधिक सुरक्षित आहेत कारण त्या प्रामाणिक वर्तनाला थेट प्रोत्साहन देतात. + +## डेटा उपलब्धता आणि लाईट नोड्स {#data-availability-and-light-nodes} + +[लाईट नोड्सना](/developers/docs/nodes-and-clients/light-clients) ब्लॉक डेटा डाउनलोड न करता त्यांना मिळणाऱ्या ब्लॉक हेडर्सची अचूकता सत्यापित करणे आवश्यक आहे. या हलकेपणाची किंमत म्हणजे फुल नोड्स ज्या प्रकारे स्थानिक पातळीवर व्यवहार पुन्हा कार्यान्वित करून ब्लॉक हेडर्सची स्वतंत्रपणे पडताळणी करू शकतात, तसे न करू शकणे. + +Ethereum लाईट नोड्स 512 व्हॅलिडेटर्सच्या यादृच्छिक संचांवर विश्वास ठेवतात ज्यांना _सिंक समिती_मध्ये नेमले गेले आहे. सिंक समिती एका DAC प्रमाणे कार्य करते जी लाईट क्लायंट्सना क्रिप्टोग्राफिक स्वाक्षरी वापरून सूचित करते की हेडरमधील डेटा योग्य आहे. दररोज, सिंक समिती रिफ्रेश होते. प्रत्येक ब्लॉक हेडर लाईट नोड्सना सावध करतो की कोणत्या व्हॅलिडेटर्सकडून _पुढील_ ब्लॉकवर स्वाक्षरीची अपेक्षा करावी, त्यामुळे त्यांना खऱ्या सिंक-समितीचे ढोंग करणाऱ्या दुर्भावनापूर्ण गटावर विश्वास ठेवण्यासाठी फसवले जाऊ शकत नाही. + +तथापि, जर एखाद्या आक्रमणकर्त्याने लाईट क्लायंट्सना एक दुर्भावनापूर्ण ब्लॉक हेडर पाठवण्यात आणि तो एका प्रामाणिक सिंक-समितीने स्वाक्षरी केलेला आहे यावर त्यांचा विश्वास बसवण्यात यश मिळवले तर काय होईल? त्या बाबतीत, आक्रमणकर्ता अवैध व्यवहार समाविष्ट करू शकतो आणि लाईट क्लायंट त्यांना आंधळेपणाने स्वीकारेल, कारण ते ब्लॉक हेडरमध्ये सारांशित केलेले सर्व स्टेट बदल स्वतंत्रपणे तपासत नाहीत. यापासून संरक्षण करण्यासाठी, लाईट क्लायंट फ्रॉड प्रूफ्सचा वापर करू शकतो. + +हे फ्रॉड प्रूफ्स ज्या प्रकारे काम करतात ते असे आहे की, नेटवर्कमध्ये अवैध स्टेट ट्रांझिशन पसरताना पाहून एक फुल नोड त्वरीत डेटाचा एक छोटा तुकडा तयार करू शकतो, जो हे दर्शवतो की प्रस्तावित स्टेट ट्रांझिशन दिलेल्या व्यवहारांच्या संचामधून शक्य नाही, आणि तो डेटा पिअर्सना प्रसारित करू शकतो. लाईट नोड्स ते फ्रॉड-प्रूफ्स घेऊ शकतात आणि खराब ब्लॉक हेडर्स टाकून देण्यासाठी त्यांचा वापर करू शकतात, ज्यामुळे ते फुल नोड्सप्रमाणेच प्रामाणिक चेनवर राहतील याची खात्री होते. + +हे फुल नोड्सना पूर्ण व्यवहार डेटाचा ऍक्सेस असण्यावर अवलंबून आहे. एक आक्रमणकर्ता जो एक खराब ब्लॉक हेडर प्रसारित करतो आणि व्यवहार डेटा उपलब्ध करून देण्यात अपयशी ठरतो, तो फुल नोड्सना फ्रॉड प्रूफ्स तयार करण्यापासून रोखू शकतो. फुल नोड्स कदाचित एका खराब ब्लॉकबद्दल चेतावणी देऊ शकतील, परंतु ते त्यांच्या चेतावणीला पुराव्यासह दुजोरा देऊ शकणार नाहीत, कारण पुरावा तयार करण्यासाठी डेटा उपलब्ध करून दिला गेला नव्हता! + +या डेटा उपलब्धता समस्येवर उपाय म्हणजे DAS. लाईट नोड्स संपूर्ण स्टेट डेटाचे खूप लहान यादृच्छिक तुकडे डाउनलोड करतात आणि संपूर्ण डेटा संच उपलब्ध असल्याची पडताळणी करण्यासाठी त्या नमुन्यांचा वापर करतात. N यादृच्छिक चंक्स डाउनलोड केल्यानंतर पूर्ण डेटा उपलब्ध आहे असे चुकीने गृहीत धरण्याची वास्तविक शक्यता मोजली जाऊ शकते ([100 चंक्ससाठी ही शक्यता 10^-30 आहे](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), म्हणजे, अविश्वसनीयपणे अशक्य). + +या परिस्थितीतही, केवळ काही बाइट्स रोखून ठेवणारे हल्ले यादृच्छिक डेटा विनंत्या करणाऱ्या क्लायंट्सच्या लक्षात न येण्याची शक्यता आहे. इरेजर कोडिंग डेटाचे गहाळ झालेले छोटे तुकडे पुन्हा तयार करून ही समस्या दूर करते, ज्याचा उपयोग प्रस्तावित स्टेट बदल तपासण्यासाठी केला जाऊ शकतो. त्यानंतर पुनर्रचित डेटा वापरून एक फ्रॉड प्रूफ तयार केला जाऊ शकतो, ज्यामुळे लाईट नोड्सना खराब हेडर्स स्वीकारण्यापासून रोखता येते. + +**टीप:** प्रूफ-ऑफ-स्टेक Ethereum लाईट क्लायंटसाठी DAS आणि फ्रॉड प्रूफ्स अद्याप लागू केलेले नाहीत, परंतु ते रोडमॅपवर आहेत, आणि बहुधा ZK-SNARK आधारित प्रूफ्सच्या स्वरूपात असतील. आजचे लाईट क्लायंट DAC च्या एका प्रकारावर अवलंबून आहेत: ते सिंक-समितीच्या ओळखीची पडताळणी करतात आणि नंतर त्यांना मिळालेल्या स्वाक्षरी केलेल्या ब्लॉक हेडर्सवर विश्वास ठेवतात. + +## डेटा उपलब्धता आणि लेयर 2 रोलअप्स {#data-availability-and-layer-2-rollups} + +[लेयर 2 स्केलिंग सोल्यूशन्स](/layer-2/), जसे की [रोलअप्स](/glossary/#rollups), ऑफचेन व्यवहारांवर प्रक्रिया करून व्यवहार खर्च कमी करतात आणि Ethereum चा थ्रुपुट वाढवतात. रोलअप व्यवहार संकुचित केले जातात आणि बॅचमध्ये Ethereum वर पोस्ट केले जातात. बॅचेस Ethereum वरील एकाच व्यवहारामध्ये हजारो वैयक्तिक ऑफचेन व्यवहारांचे प्रतिनिधित्व करतात. हे बेस लेयरवरील गर्दी कमी करते आणि वापरकर्त्यांसाठी शुल्क कमी करते. + +तथापि, Ethereum वर पोस्ट केलेल्या 'सारांश' व्यवहारांवर तेव्हाच विश्वास ठेवणे शक्य आहे जेव्हा प्रस्तावित स्टेट बदलाची स्वतंत्रपणे पडताळणी केली जाऊ शकते आणि सर्व वैयक्तिक ऑफचेन व्यवहार लागू केल्याचा तो परिणाम असल्याची पुष्टी केली जाऊ शकते. जर रोलअप ऑपरेटर्सनी या पडताळणीसाठी व्यवहार डेटा उपलब्ध करून दिला नाही, तर ते Ethereum ला चुकीचा डेटा पाठवू शकतात. + +[ऑप्टिमिस्टिक रोलअप्स](/developers/docs/scaling/optimistic-rollups/) संकुचित व्यवहार डेटा Ethereum वर पोस्ट करतात आणि स्वतंत्र पडताळणीकर्त्यांना डेटा तपासण्याची परवानगी देण्यासाठी काही कालावधीसाठी (सामान्यतः 7 दिवस) प्रतीक्षा करतात. जर कोणाला समस्या आढळली, तर ते एक फ्रॉड-प्रूफ तयार करू शकतात आणि रोलअपला आव्हान देण्यासाठी त्याचा वापर करू शकतात. यामुळे चेन रोल बॅक होईल आणि अवैध ब्लॉक वगळला जाईल. हे केवळ डेटा उपलब्ध असल्यास शक्य आहे. सध्या, ऑप्टिमिस्टिक रोलअप्स L1 वर व्यवहार डेटा पोस्ट करण्याचे दोन मार्ग आहेत. काही रोलअप्स डेटा `CALLDATA` म्हणून कायमस्वरूपी उपलब्ध करून देतात जो ऑनचेन कायमस्वरूपी राहतो. EIP-4844 च्या अंमलबजावणीसह, काही रोलअप्स आपला व्यवहार डेटा त्याऐवजी स्वस्त ब्लॉब स्टोरेजवर पोस्ट करतात. हे कायमस्वरूपी स्टोरेज नाही. Ethereum लेयर-1 मधून डेटा हटवण्यापूर्वी स्वतंत्र पडताळणीकर्त्यांना ~18 दिवसांच्या आत ब्लॉब्सची क्वेरी करावी लागते आणि आपली आव्हाने मांडावी लागतात. त्या लहान निश्चित विंडोसाठी डेटाची उपलब्धता केवळ Ethereum प्रोटोकॉलद्वारे हमी दिली जाते. त्यानंतर, ती Ethereum परिसंस्थेतील इतर घटकांची जबाबदारी बनते. कोणताही नोड DAS वापरून डेटाची उपलब्धता सत्यापित करू शकतो, म्हणजेच, ब्लॉब डेटाचे छोटे, यादृच्छिक नमुने डाउनलोड करून. + +[झिरो-नॉलेज (ZK) रोलअप्सना](/developers/docs/scaling/zk-rollups) व्यवहार डेटा पोस्ट करण्याची आवश्यकता नाही कारण [झिरो-नॉलेज व्हॅलिडिटी प्रूफ्स](/glossary/#zk-proof) स्टेट ट्रांझिशनच्या अचूकतेची हमी देतात. तथापि, डेटा उपलब्धता अजूनही एक समस्या आहे कारण आपण ZK-रोलअपच्या स्टेट डेटामध्ये प्रवेश केल्याशिवाय त्याच्या कार्यक्षमतेची हमी देऊ शकत नाही (किंवा त्याच्याशी संवाद साधू शकत नाही). उदाहरणार्थ, जर एखाद्या ऑपरेटरने रोलअपच्या स्टेटबद्दल तपशील रोखून ठेवला तर वापरकर्ते त्यांचे बॅलन्स जाणून घेऊ शकत नाहीत. तसेच, ते नव्याने जोडलेल्या ब्लॉकमध्ये असलेली माहिती वापरून स्टेट अपडेट्स करू शकत नाहीत. + +## डेटा उपलब्धता विरुद्ध डेटा पुनर्प्राप्ती {#data-availability-vs-data-retrievability} + +डेटा उपलब्धता ही डेटा पुनर्प्राप्तीपेक्षा वेगळी आहे. डेटा उपलब्धता ही खात्री आहे की फुल नोड्स एका विशिष्ट ब्लॉकशी संबंधित व्यवहारांच्या संपूर्ण संचावर प्रवेश करू शकले आहेत आणि त्याची पडताळणी करू शकले आहेत. याचा अर्थ असा नाही की डेटा कायमस्वरूपी उपलब्ध आहे. + +डेटा पुनर्प्राप्ती म्हणजे नोड्सची ब्लॉकचेनमधून _ऐतिहासिक माहिती_ पुनर्प्राप्त करण्याची क्षमता. नवीन ब्लॉक्सची पडताळणी करण्यासाठी या ऐतिहासिक डेटाची आवश्यकता नाही, तो फक्त जेनेसिस ब्लॉकमधून फुल नोड्स सिंक करण्यासाठी किंवा विशिष्ट ऐतिहासिक विनंत्या पूर्ण करण्यासाठी आवश्यक आहे. + +मूळ Ethereum प्रोटोकॉल प्रामुख्याने डेटा उपलब्धतेशी संबंधित आहे, डेटा पुनर्प्राप्तीशी नाही. डेटा पुनर्प्राप्ती तृतीय पक्षांद्वारे चालवल्या जाणाऱ्या अर्काइव्ह नोड्सच्या लहान लोकसंख्येद्वारे प्रदान केली जाऊ शकते, किंवा [पोर्टल नेटवर्क](https://www.ethportal.net/) सारख्या विकेंद्रित फाइल स्टोरेजचा वापर करून नेटवर्कवर वितरित केली जाऊ शकते. + +## पुढील वाचन {#further-reading} + +- [डेटा उपलब्धता म्हणजे काय?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [डेटा उपलब्धता काय आहे?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [डेटा उपलब्धता तपासणीवर एक प्राइमर](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [शार्डिंग + DAS प्रस्तावाचे स्पष्टीकरण](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [डेटा उपलब्धता आणि इरेजर कोडिंगवर एक टीप](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [डेटा उपलब्धता समित्या.](https://medium.com/starkware/data-availability-e5564c416424) +- [प्रूफ-ऑफ-स्टेक डेटा उपलब्धता समित्या.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [डेटा पुनर्प्राप्ती समस्येवरील उपाय](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [डेटा उपलब्धता किंवा: रोलअप्स कसे काळजी करणे सोडून Ethereum वर प्रेम करायला शिकले](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: कॉलडेटा खर्च वाढवणे](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/mr/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/mr/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..c7307835df7 --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "डेटा संरचना आणि एन्कोडिंग" +description: "मूलभूत Ethereum डेटा स्ट्रक्चर्सचा आढावा." +lang: mr +sidebarDepth: 2 +--- + +Ethereum मोठ्या प्रमाणात डेटा तयार करते, साठवते आणि हस्तांतरित करते. हा डेटा प्रमाणित आणि मेमरी-कार्यक्षम मार्गांनी स्वरूपित करणे आवश्यक आहे, जेणेकरून कोणीही तुलनेने सामान्य ग्राहक-श्रेणी हार्डवेअरवर [एक नोड चालवू](/run-a-node/) शकेल. हे साध्य करण्यासाठी, Ethereum स्टॅकवर अनेक विशिष्ट डेटा स्ट्रक्चर्स वापरल्या जातात. + +## पूर्वतयारी {#prerequisites} + +आपण Ethereum ची मूलभूत तत्त्वे आणि [क्लायंट सॉफ्टवेअर](/developers/docs/nodes-and-clients/) समजून घेतले पाहिजे. नेटवर्किंग लेअर आणि [Ethereum श्वेतपत्रिकेची](/whitepaper/) माहिती असण्याची शिफारस केली जाते. + +## डेटा स्ट्रक्चर्स {#data-structures} + +### पॅट्रिशिया मर्केल ट्राइज {#patricia-merkle-tries} + +पॅट्रिशिया मर्केल ट्राइज अशा रचना आहेत ज्या की-व्हॅल्यू जोड्यांना एका निश्चित आणि क्रिप्टोग्राफिकली प्रमाणीकृत ट्राइमध्ये एन्कोड करतात. Ethereum च्या एक्झिक्युशन लेअरवर यांचा मोठ्या प्रमाणावर वापर केला जातो. + +[पॅट्रिशिया मर्केल ट्राइजबद्दल अधिक](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### रिकर्सिव्ह लेंथ प्रीफिक्स {#recursive-length-prefix} + +रिकर्सिव्ह लेंथ प्रीफिक्स (RLP) ही एक सिरिअलायझेशन पद्धत आहे जी Ethereum च्या एक्झिक्युशन लेअरवर मोठ्या प्रमाणावर वापरली जाते. + +[RLP बद्दल अधिक](/developers/docs/data-structures-and-encoding/rlp) + +### सिंपल सिरिअलाइज {#simple-serialize} + +सिंपल सिरिअलाइज (SSZ) हे Ethereum च्या कन्सेन्सस लेअरवरील प्रमुख सिरिअलायझेशन स्वरूप आहे, कारण ते मर्केलायझेशनशी सुसंगत आहे. + +[SSZ बद्दल अधिक](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/mr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/mr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..446e0f6a761 --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "मर्केल पॅट्रिशिया ट्राई" +description: "मर्केल पॅट्रिशिया ट्राईची ओळख." +lang: mr +sidebarDepth: 2 +--- + +Ethereum ची स्टेट (सर्व अकाउंट्स, बॅलन्स आणि स्मार्ट कॉन्ट्रॅक्ट्सची एकूणता), डेटा स्ट्रक्चरच्या एका विशेष आवृत्तीमध्ये एन्कोड केली जाते, जी संगणक विज्ञानात सामान्यतः मर्केल ट्री म्हणून ओळखली जाते. ही रचना क्रिप्टोग्राफीमधील अनेक ॲप्लिकेशन्ससाठी उपयुक्त आहे कारण ती ट्रीमध्ये गुंतलेल्या डेटाच्या सर्व वैयक्तिक भागांमध्ये एक सत्यापित करण्यायोग्य संबंध तयार करते, ज्यामुळे एकच **रूट** व्हॅल्यू तयार होते ज्याचा वापर डेटाबद्दल गोष्टी सिद्ध करण्यासाठी केला जाऊ शकतो. + +Ethereum ची डेटा स्ट्रक्चर एक 'मॉडिफाइड मर्केल-पॅट्रिशिया ट्राई' आहे, ज्याला हे नाव दिले गेले आहे कारण ते PATRICIA (प्रॅक्टिकल अल्गोरिदम टू रिट्रीव्ह इन्फॉर्मेशन कोडेड इन अल्फान्यूमेरिक) चे काही वैशिष्ट्ये घेते आणि कारण ते Ethereum स्टेट तयार करणाऱ्या आयटम्सच्या कार्यक्षम डेटा रि**ट्राई**व्हलसाठी डिझाइन केलेले आहे. + +मर्केल-पॅट्रिशिया ट्राई ही निश्चित (deterministic) आणि क्रिप्टोग्राफिकदृष्ट्या सत्यापित करण्यायोग्य आहे: स्टेट रूट तयार करण्याचा एकमेव मार्ग म्हणजे स्टेटच्या प्रत्येक वैयक्तिक भागातून त्याची गणना करणे आणि दोन सारख्याच स्टेट्सची रूट हॅश आणि त्यापर्यंत पोहोचलेल्या हॅशेसची तुलना करून सहजपणे सिद्ध करता येते (_एक मर्केल प्रूफ_). याउलट, एकाच रूट हॅशसह दोन भिन्न स्टेट्स तयार करण्याचा कोणताही मार्ग नाही आणि भिन्न मूल्यांसह स्टेटमध्ये बदल करण्याचा कोणताही प्रयत्न केल्यास भिन्न स्टेट रूट हॅश मिळेल. सैद्धांतिकदृष्ट्या, ही रचना इन्सर्ट, लुकअप आणि डिलीटसाठी `O(log(n))` कार्यक्षमतेचे 'होली ग्रेल' प्रदान करते. + +नजीकच्या भविष्यात, Ethereum [Verkle Tree](/roadmap/verkle-trees) रचनेमध्ये स्थलांतरित करण्याची योजना आखत आहे, ज्यामुळे भविष्यातील प्रोटोकॉल सुधारणांसाठी अनेक नवीन शक्यता उघडल्या जातील. + +## पूर्वतयारी {#prerequisites} + +हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, [हॅशेस](https://en.wikipedia.org/wiki/Hash_function), [मर्केल ट्रीज](https://en.wikipedia.org/wiki/Merkle_tree), [ट्राईज](https://en.wikipedia.org/wiki/Trie) आणि [सीरियलायझेशन](https://en.wikipedia.org/wiki/Serialization) यांचे मूलभूत ज्ञान असणे उपयुक्त ठरेल. हा लेख मूलभूत [रॅडिक्स ट्री](https://en.wikipedia.org/wiki/Radix_tree) च्या वर्णनाने सुरू होतो, नंतर हळूहळू Ethereum च्या अधिक ऑप्टिमाइझ केलेल्या डेटा स्ट्रक्चरसाठी आवश्यक बदल सादर करतो. + +## मूलभूत रॅडिक्स ट्राईज {#basic-radix-tries} + +मूलभूत रॅडिक्स ट्राईमध्ये, प्रत्येक नोड खालीलप्रमाणे दिसतो: + +``` + [i_0, i_1 ... i_n, value] +``` + +जिथे `i_0 ... i_n` वर्णमालेची चिन्हे दर्शवतात (बहुतेकदा बायनरी किंवा हेक्स), `व्हॅल्यू` नोडमधील टर्मिनल व्हॅल्यू आहे, आणि `i_0, i_1 ... ` मधील व्हॅल्यूज i_n`स्लॉट एकतर`NULL`किंवा इतर नोड्सचे पॉइंटर्स (आमच्या बाबतीत, हॅश) असतात. हे एक मूलभूत`(की, व्हॅल्यू)` स्टोअर तयार करते. + +समजा तुम्हाला की-व्हॅल्यू जोड्यांच्या सेटवर ऑर्डर कायम ठेवण्यासाठी रॅडिक्स ट्री डेटा स्ट्रक्चर वापरायचे आहे. ट्राईमध्ये सध्या `dog` की शी मॅप केलेली व्हॅल्यू शोधण्यासाठी, तुम्ही प्रथम `dog` ला वर्णमालेच्या अक्षरांमध्ये रूपांतरित कराल ( `64 6f 67` देऊन), आणि नंतर तुम्हाला व्हॅल्यू मिळेपर्यंत त्या मार्गावरून ट्राईमध्ये खाली जाल. म्हणजे, तुम्ही ट्राईचा रूट नोड शोधण्यासाठी फ्लॅट की/व्हॅल्यू DB मध्ये रूट हॅश शोधून सुरुवात करता. ते इतर नोड्सना पॉइंट करणाऱ्या कीजच्या ॲरे म्हणून दर्शविले जाते. तुम्ही इंडेक्स `6` वरील व्हॅल्यूचा की म्हणून वापर कराल आणि एका लेव्हल खालील नोड मिळवण्यासाठी फ्लॅट की/व्हॅल्यू DB मध्ये शोधाल. नंतर पुढील व्हॅल्यू शोधण्यासाठी इंडेक्स `4` निवडा, नंतर इंडेक्स `6` निवडा, आणि असेच, जोपर्यंत तुम्ही मार्ग: `रूट -> 6 -> 4 -> 6 -> 15 -> 6 -> 7` फॉलो करत नाही, तोपर्यंत तुम्ही नोडची व्हॅल्यू शोधून निकाल परत कराल. + +'ट्राई' मध्ये काहीतरी शोधणे आणि अंतर्निहित फ्लॅट की/व्हॅल्यू 'DB' मध्ये शोधणे यात फरक आहे. ते दोघेही की/व्हॅल्यू व्यवस्था परिभाषित करतात, परंतु अंतर्निहित DB की चा पारंपरिक 1-स्टेप लुकअप करू शकतो. ट्राईमध्ये की शोधण्यासाठी वर वर्णन केलेल्या अंतिम व्हॅल्यूपर्यंत पोहोचण्यासाठी अनेक अंतर्निहित DB लुकअप्सची आवश्यकता असते. अस्पष्टता दूर करण्यासाठी आपण नंतरच्याला `पाथ` म्हणूया. + +रॅडिक्स ट्राईजसाठी अपडेट आणि डिलीट ऑपरेशन्स खालीलप्रमाणे परिभाषित केल्या जाऊ शकतात: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash else [NULL] * 17 + newnode = curnode.copy() + if path == "": + newnode[-1] = value + else: + newindex = update(curnode[path[0]], path[1:], value) + newnode[path[0]] = newindex + db.put(hash(newnode), newnode) + return hash(newnode) + + def delete(node_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + newnode = curnode.copy() + if path == "": + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]], path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode), newnode) + return hash(newnode) +``` + +एक "मर्केल" रॅडिक्स ट्री निश्चितपणे-उत्पादित क्रिप्टोग्राफिक हॅश डायजेस्ट वापरून नोड्स लिंक करून तयार केली जाते. हे कंटेंट-ॲड्रेसिंग (की/व्हॅल्यू DB मध्ये `की == keccak256(rlp(व्हॅल्यू))`) संग्रहित डेटाची क्रिप्टोग्राफिक अखंडतेची हमी देते. जर दिलेल्या ट्राईचा रूट हॅश सार्वजनिकरित्या ज्ञात असेल, तर अंतर्निहित लीफ डेटामध्ये प्रवेश असलेला कोणीही विशिष्ट व्हॅल्यूला ट्री रूटशी जोडणाऱ्या प्रत्येक नोडचे हॅश प्रदान करून, ट्राईमध्ये विशिष्ट मार्गावर विशिष्ट व्हॅल्यू समाविष्ट असल्याचा पुरावा तयार करू शकतो. + +आक्रमणकर्त्यासाठी अस्तित्वात नसलेल्या `(पाथ, व्हॅल्यू)` जोडीचा पुरावा देणे अशक्य आहे कारण रूट हॅश शेवटी त्याच्या खालील सर्व हॅशवर आधारित असतो. कोणत्याही अंतर्निहित बदलामुळे रूट हॅश बदलेल. आपण हॅशला डेटाच्या संरचनात्मक माहितीचे संकुचित प्रतिनिधित्व म्हणून विचार करू शकता, जे हॅशिंग फंक्शनच्या प्री-इमेज संरक्षणाद्वारे सुरक्षित केलेले आहे. + +आपण रॅडिक्स ट्रीच्या अणु एककाला (उदा., एकच हेक्स कॅरॅक्टर किंवा 4 बिट बायनरी संख्या) "निबल" म्हणू. वर वर्णन केल्याप्रमाणे, एका वेळी एक निबल मार्गक्रमण करताना, नोड्स जास्तीत जास्त 16 चिल्ड्रेनचा संदर्भ घेऊ शकतात परंतु त्यात `व्हॅल्यू` घटक समाविष्ट असतो. म्हणून, आम्ही त्यांना 17 लांबीच्या ॲरे म्हणून दर्शवितो. आम्ही या 17-घटक ॲरेला "ब्रांच नोड्स" म्हणतो. + +## मर्केल पॅट्रिशिया ट्राई {#merkle-patricia-trees} + +रॅडिक्स ट्राईजची एक मोठी मर्यादा आहे: त्या अकार्यक्षम आहेत. जर तुम्हाला एक `(पाथ, व्हॅल्यू)` बाइंडिंग साठवायचे असेल जिथे पाथ, Ethereum प्रमाणे, 64 कॅरॅक्टर लांब आहे (`bytes32` मधील निबल्सची संख्या), तर आम्हाला प्रत्येक कॅरॅक्टरसाठी एक लेव्हल साठवण्यासाठी एक किलोबाइटपेक्षा जास्त अतिरिक्त जागेची आवश्यकता असेल, आणि प्रत्येक लुकअप किंवा डिलीटसाठी पूर्ण 64 स्टेप्स लागतील. खालीलप्रमाणे सादर केलेली पॅट्रिशिया ट्राई ही समस्या सोडवते. + +### ऑप्टिमायझेशन {#optimization} + +मर्केल पॅट्रिशिया ट्राईमधील नोड खालीलपैकी एक असतो: + +1. `NULL` (रिकाम्या स्ट्रिंगने दर्शविलेले) +2. `ब्रांच` एक 17-आयटम नोड `[ v0 ... v15, vt ]` +3. `लीफ` एक 2-आयटम नोड `[ एन्कोडेडपाथ, व्हॅल्यू ]` +4. `एक्सटेन्शन` एक 2-आयटम नोड `[ एन्कोडेडपाथ, की ]` + +64 कॅरॅक्टर पाथसह, ट्राईच्या पहिल्या काही लेयर्समधून गेल्यानंतर, तुम्ही अशा नोडवर पोहोचणारच आहात जिथे किमान काही मार्गासाठी कोणताही भिन्न मार्ग अस्तित्वात नाही. मार्गावर 15 पर्यंत विरळ `NULL` नोड्स तयार करणे टाळण्यासाठी, आम्ही `[ एन्कोडेडपाथ, की ]` स्वरूपाचा एक `एक्सटेन्शन` नोड सेट करून उतरण लहान करतो, जिथे `एन्कोडेडपाथ` मध्ये पुढे जाण्यासाठी "आंशिक मार्ग" असतो (खाली वर्णन केलेल्या कॉम्पॅक्ट एन्कोडिंगचा वापर करून), आणि `की` पुढील DB लुकअपसाठी असते. + +`लीफ` नोडसाठी, जे `एन्कोडेडपाथ`च्या पहिल्या निबलमधील ध्वजाद्वारे चिन्हांकित केले जाऊ शकते, पाथमध्ये मागील सर्व नोडच्या पाथच्या तुकड्यांचे एन्कोडिंग असते आणि आम्ही थेट `व्हॅल्यू` शोधू शकतो. + +तथापि, वरील ऑप्टिमायझेशनमुळे संदिग्धता निर्माण होते. + +निबल्समध्ये पाथक्रमण करताना, आपल्याला विषम संख्येने निबल्सचा सामना करावा लागू शकतो, परंतु सर्व डेटा `बाइट्स` स्वरूपात संग्रहित असल्यामुळे. उदाहरणार्थ, निबल `1` आणि निबल्स `01` मध्ये फरक करणे शक्य नाही (दोन्ही `<01>` म्हणून संग्रहित करणे आवश्यक आहे). विषम लांबी निर्दिष्ट करण्यासाठी, आंशिक मार्गाच्या आधी एक ध्वज लावला जातो. + +### स्पेसिफिकेशन: पर्यायी टर्मिनेटरसह हेक्स सीक्वेन्सचे कॉम्पॅक्ट एन्कोडिंग {#specification} + +वर वर्णन केल्याप्रमाणे _विषम विरुद्ध सम उर्वरित आंशिक मार्गाची लांबी_ आणि _लीफ विरुद्ध एक्सटेन्शन नोड_ या दोन्हींचे ध्वजांकन कोणत्याही 2-आयटम नोडच्या आंशिक मार्गाच्या पहिल्या निबलमध्ये असते. त्यांचे परिणाम खालीलप्रमाणे आहेत: + +| हेक्स कॅरॅक्टर | बिट्स | नोड प्रकार आंशिक | पाथची लांबी | +| -------------- | ----- | ------------------------------------ | ----------- | +| 0 | 0000 | एक्सटेन्शन | सम | +| 1 | 0001 | एक्सटेन्शन | विषम | +| 2 | 0010 | टर्मिनेटिंग (लीफ) | सम | +| 3 | 0011 | टर्मिनेटिंग (लीफ) | विषम | + +सम उर्वरित पाथ लांबीसाठी (`0` किंवा `2`), नेहमीच आणखी एक `0` "पॅडिंग" निबल येईल. + +```python + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: + hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + # hexarray now has an even length whose first nibble is the flags. + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +उदाहरणे: + +```python + > [1, 2, 3, 4, 5, ...] + '11 23 45' + > [0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +मर्केल पॅट्रिशिया ट्राईमध्ये नोड मिळवण्यासाठी विस्तारित कोड येथे आहे: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[: len(k2)]: + return get(v2, path[len(k2) :]) + else: + return "" + elif len(curnode) == 17: + return get_helper(curnode[path[0]], path[1:]) + + def get(node_hash, path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node_hash, path2) +``` + +### उदाहरण ट्राई {#example-trie} + +समजा आपल्याला चार पाथ/व्हॅल्यू जोड्या असलेली ट्राई हवी आहे: `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. + +प्रथम, आपण पाथ आणि व्हॅल्यू दोन्ही `बाइट्स` मध्ये रूपांतरित करतो. खाली, _पाथ_ साठी वास्तविक बाइट रिप्रेझेंटेशन्स `<>` ने दर्शविले आहेत, तरीही _व्हॅल्यू_ सोप्या समजुतीसाठी `''` ने दर्शविलेल्या स्ट्रिंग म्हणून दाखवल्या आहेत (त्या देखील वास्तविकपणे `बाइट्स` असतील): + +``` + <64 6f> : 'क्रियापद' + <64 6f 67> : 'पिल्लू' + <64 6f 67 65> : 'नाणी' + <68 6f 72 73 65> : 'घोडा' +``` + +आता, आपण अंतर्निहित DB मध्ये खालील की/व्हॅल्यू जोड्यांसह अशी ट्राई तयार करू: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'घोडा' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'क्रियापद' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'नाणी' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'पिल्लू' ] ] +``` + +जेव्हा एका नोडचा दुसऱ्या नोडमध्ये संदर्भ दिला जातो, तेव्हा `keccak256(rlp.encode(node))` समाविष्ट केले जाते, जर `len(rlp.encode(node)) >= 32` असेल तर, अन्यथा `node` समाविष्ट केले जाते जिथे `rlp.encode` हे [RLP](/developers/docs/data-structures-and-encoding/rlp) एन्कोडिंग फंक्शन आहे. + +लक्षात घ्या की ट्राई अपडेट करताना, जर नव्याने तयार केलेला नोड 32 किंवा त्यापेक्षा जास्त लांबीचा असेल तर, की/व्हॅल्यू जोडी `(keccak256(x), x)` एका पर्सिस्टंट लुकअप टेबलमध्ये साठवणे आवश्यक आहे. तथापि, जर नोड त्यापेक्षा लहान असेल, तर काहीही साठवण्याची गरज नाही, कारण f(x) = x हे फंक्शन उलट करता येण्याजोगे आहे. + +## Ethereum मधील ट्राईज {#tries-in-ethereum} + +Ethereum च्या एक्झिक्युशन लेअरमधील सर्व मर्केल ट्राईज मर्केल पॅट्रिशिया ट्राई वापरतात. + +ब्लॉक हेडरमधून यापैकी 3 ट्राईजचे 3 रूट्स असतात. + +1. स्टेटरूट +2. ट्रान्झॅक्शन्सरूट +3. रीसीट्सरूट + +### स्टेट ट्राई {#state-trie} + +एक जागतिक स्टेट ट्राई आहे, आणि जेव्हा एखादा क्लायंट ब्लॉकवर प्रक्रिया करतो तेव्हा ती प्रत्येक वेळी अपडेट केली जाते. त्यात, एक `पाथ` नेहमी असतो: `keccak256(ethereumAddress)` आणि एक `व्हॅल्यू` नेहमी असते: `rlp(ethereumAccount)`. अधिक विशेषतः, एक Ethereum `अकाउंट` `[nonce,balance,storageRoot,codeHash]` या 4 आयटमचा ॲरे आहे. या टप्प्यावर, हे लक्षात घेण्यासारखे आहे की हा `storageRoot` दुसऱ्या पॅट्रिशिया ट्राईचा रूट आहे: + +### स्टोरेज ट्राई {#storage-trie} + +स्टोरेज ट्राई हे असे ठिकाण आहे जिथे _सर्व_ कॉन्ट्रॅक्ट डेटा राहतो. प्रत्येक अकाउंटसाठी स्वतंत्र स्टोरेज ट्राई असते. विशिष्ट ॲड्रेसवर विशिष्ट स्टोरेज पोझिशनवरील व्हॅल्यूज मिळवण्यासाठी स्टोरेज ॲड्रेस, स्टोरेजमध्ये संग्रहित डेटाची पूर्णांक पोझिशन आणि ब्लॉक आयडी आवश्यक आहेत. त्यानंतर JSON-RPC API मध्ये परिभाषित `eth_getStorageAt` ला आर्गुमेंट्स म्हणून पास केले जाऊ शकते, उदा., ॲड्रेस `0x295a70b2de5e3953354a6a8344e616ed314d7251` साठी स्टोरेज स्लॉट 0 मधील डेटा मिळवण्यासाठी: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +स्टोरेजमधील इतर घटक मिळवणे थोडे अधिक गुंतागुंतीचे आहे कारण स्टोरेज ट्राईमधील पोझिशनची प्रथम गणना करणे आवश्यक आहे. पोझिशनची गणना ॲड्रेस आणि स्टोरेज पोझिशनच्या `keccak256` हॅश म्हणून केली जाते, दोन्ही 32 बाइट्सच्या लांबीपर्यंत शून्यांसह डावीकडे पॅड केलेले असतात. उदाहरणार्थ, ॲड्रेस `0x391694e7e0b0cce554cb130d723a9d27458f9298` साठी स्टोरेज स्लॉट 1 मधील डेटाची पोझिशन आहे: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +Geth कन्सोलमध्ये, याची गणना खालीलप्रमाणे केली जाऊ शकते: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +म्हणून `पाथ` `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` आहे. हे आता पूर्वीप्रमाणेच स्टोरेज ट्राईमधून डेटा मिळवण्यासाठी वापरले जाऊ शकते: + +```bash +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +टीप: जर ते कॉन्ट्रॅक्ट अकाउंट नसेल तर Ethereum अकाउंटसाठी `storageRoot` डिफॉल्टनुसार रिकामा असतो. + +### ट्रान्झॅक्शन ट्राई {#transaction-trie} + +प्रत्येक ब्लॉकसाठी एक वेगळी ट्रान्झॅक्शन ट्राई असते, जी पुन्हा `(की, व्हॅल्यू)` जोड्या साठवते. येथे एक पाथ आहे: `rlp(transactionIndex)` जो एका व्हॅल्यूशी संबंधित की दर्शवितो, जी याद्वारे निर्धारित केली जाते: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +याबद्दल अधिक माहिती [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) डॉक्युमेंटेशनमध्ये आढळू शकते. + +### रीसीट्स ट्राई {#receipts-trie} + +प्रत्येक ब्लॉकची स्वतःची रीसीट्स ट्राई असते. येथे एक `पाथ` आहे: `rlp(transactionIndex)`. `transactionIndex` हा ज्या ब्लॉक मध्ये त्याचा समावेश आहे त्यातील त्याचा इंडेक्स आहे. रीसीट्स ट्राई कधीही अपडेट केली जात नाही. ट्रान्झॅक्शन ट्राई प्रमाणेच, सध्याच्या आणि लेगसी रीसीट्स आहेत. रीसीट्स ट्राईमध्ये विशिष्ट रीसीट क्वेरी करण्यासाठी, त्याच्या ब्लॉकमधील ट्रान्झॅक्शनचा इंडेक्स, रीसीट पेलोड आणि ट्रान्झॅक्शन प्रकार आवश्यक आहे. परत आलेली रीसीट `Receipt` प्रकाराची असू शकते जी `TransactionType` आणि `ReceiptPayload` चे एकत्रीकरण म्हणून परिभाषित केली आहे किंवा ती `LegacyReceipt` प्रकाराची असू शकते जी `rlp([status, cumulativeGasUsed, logsBloom, logs])` म्हणून परिभाषित केली आहे. + +याबद्दल अधिक माहिती [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) डॉक्युमेंटेशनमध्ये आढळू शकते. + +## अधिक वाचन {#further-reading} + +- [सुधारित मर्केल पॅट्रिशिया ट्राई — Ethereum स्टेट कसे सेव्ह करते](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Ethereum मधील मर्कलिंग](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Ethereum ट्राई समजून घेणे](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/mr/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/mr/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..0cfe3d990e6 --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "रिकर्सिव्ह-लेंग्थ प्रीफिक्स (RLP) सिरियलायझेशन" +description: "Ethereum च्या एक्सिक्युशन लेअरमधील rlp एन्कोडिंगची व्याख्या." +lang: mr +sidebarDepth: 2 +--- + +रिकर्सिव्ह लेंग्थ प्रीफिक्स (RLP) सिरियलायझेशनचा वापर Ethereum च्या एक्सिक्युशन क्लायंट्समध्ये मोठ्या प्रमाणावर केला जातो. RLP नोड्समधील डेटाच्या हस्तांतरणाला स्पेस-एफिशिएंट फॉरमॅटमध्ये प्रमाणित करते. RLP चा उद्देश बायनरी डेटाच्या अनियंत्रितपणे नेस्टेड अॅरेंना एन्कोड करणे आहे आणि RLP ही Ethereum च्या एक्सिक्युशन लेअरमधील ऑब्जेक्ट्स सिरियलाइज करण्यासाठी वापरली जाणारी प्राथमिक एन्कोडिंग पद्धत आहे. RLP चा मुख्य उद्देश स्ट्रक्चर एन्कोड करणे आहे; धन पूर्णांक वगळता, RLP विशिष्ट डेटा प्रकारांचे (उदा., स्ट्रिंग, फ्लोट्स) एन्कोडिंग हायर-ऑर्डर प्रोटोकॉलकडे सोपवते. धन पूर्णांक बिग-एंडियन बायनरी स्वरूपात कोणत्याही लीडिंग शून्येशिवाय दर्शविले पाहिजेत (त्यामुळे पूर्णांक मूल्य शून्य हे रिक्त बाइट अॅरेच्या समतुल्य होते). लीडिंग शून्य असलेले डिसेरियलाइज्ड धन पूर्णांक RLP वापरणाऱ्या कोणत्याही हायर-ऑर्डर प्रोटोकॉलद्वारे अवैध मानले पाहिजेत. + +अधिक माहिती [Ethereum यलो पेपर (परिशिष्ट B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) मध्ये. + +डिक्शनरी एन्कोड करण्यासाठी RLP वापरण्याकरिता, दोन सुचवलेले कॅनोनिकल फॉर्म आहेत: + +- लेक्सिकोग्राफिक क्रमाने की सह `[[k1,v1],[k2,v2]...]` वापरा +- Ethereum प्रमाणे हायर-लेव्हल पॅट्रिशिया ट्री एन्कोडिंग वापरा + +## व्याख्या {#definition} + +RLP एन्कोडिंग फंक्शन एक आयटम इनपुट म्हणून घेते. आयटमची व्याख्या खालीलप्रमाणे आहे: + +- एक स्ट्रिंग (म्हणजेच, बाइट अॅरे) एक आयटम आहे +- आयटम्सची एक यादी हा एक आयटम आहे +- एक धन पूर्णांक एक आयटम आहे + +उदाहरणार्थ, खालील सर्व आयटम आहेत: + +- एक रिकामी स्ट्रिंग; +- "cat" हा शब्द असलेली स्ट्रिंग; +- कितीही स्ट्रिंग असलेली यादी; +- आणि `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]` सारखी अधिक जटिल डेटा स्ट्रक्चर्स. +- `100` ही संख्या + +लक्षात घ्या की या पानाच्या उर्वरित संदर्भात, 'स्ट्रिंग' याचा अर्थ "बायनरी डेटाचे विशिष्ट संख्येचे बाइट्स" आहे; कोणतेही विशेष एन्कोडिंग वापरले जात नाहीत आणि स्ट्रिंगच्या सामग्रीबद्दल कोणतेही ज्ञान सूचित केले जात नाही (नॉन-मिनिमल धन पूर्णांकांविरुद्धच्या नियमानुसार आवश्यक असल्याशिवाय). + +RLP एन्कोडिंग खालीलप्रमाणे परिभाषित केले आहे: + +- धन पूर्णांकासाठी, त्याला सर्वात लहान बाइट अॅरेमध्ये रूपांतरित केले जाते ज्याचे बिग-एंडियन इंटरप्रिटेशन तो पूर्णांक आहे, आणि नंतर खालील नियमांनुसार स्ट्रिंग म्हणून एन्कोड केले जाते. +- एका बाइटसाठी ज्याचे मूल्य `[0x00, 0x7f]` (दशांश `[0, 127]`) या रेंजमध्ये आहे, तो बाइट स्वतःच त्याचे RLP एन्कोडिंग आहे. +- अन्यथा, जर एखादी स्ट्रिंग 0-55 बाइट्स लांब असेल, तर RLP एन्कोडिंगमध्ये **0x80** (दशांश 128) मूल्याचा एक बाइट अधिक स्ट्रिंगची लांबी आणि त्यानंतर स्ट्रिंग असते. पहिल्या बाइटची रेंज `[0x80, 0xb7]` (दशांश `[128, 183]`) आहे. +- जर एखादी स्ट्रिंग 55 बाइट्सपेक्षा लांब असेल, तर RLP एन्कोडिंगमध्ये **0xb7** (दशांश 183) अधिक स्ट्रिंगच्या लांबीच्या बायनरी स्वरूपाची बाइट्समधील लांबी, हे मूल्य असलेला एक बाइट असतो. त्यानंतर स्ट्रिंगची लांबी आणि मग स्ट्रिंग असते. उदाहरणार्थ, 1024 बाइट लांबीच्या स्ट्रिंगला `\xb9\x04\x00` (दशांश `185, 4, 0`) आणि त्यानंतर स्ट्रिंग असे एन्कोड केले जाईल. येथे, पहिला बाइट `0xb9` (183 + 2 = 185) आहे, त्यानंतर 2 बाइट्स `0x0400` (दशांश 1024) येतात जे प्रत्यक्ष स्ट्रिंगची लांबी दर्शवतात. पहिल्या बाइटची रेंज `[0xb8, 0xbf]` (दशांश `[184, 191]`) आहे. +- जर एखादी स्ट्रिंग 2^64 बाइट्स लांब किंवा त्याहून अधिक लांब असेल, तर ती एन्कोड केली जाऊ शकत नाही. +- जर एखाद्या यादीचा एकूण पेलोड (म्हणजेच, RLP एन्कोड केलेल्या तिच्या सर्व आयटमची एकत्रित लांबी) 0-55 बाइट्स लांब असेल, तर RLP एन्कोडिंगमध्ये **0xc0** अधिक पेलोडची लांबी हे मूल्य असलेला एक बाइट असतो, आणि त्यानंतर आयटमच्या RLP एन्कोडिंगचे एकत्रीकरण असते. पहिल्या बाइटची रेंज `[0xc0, 0xf7]` (दशांश `[192, 247]`) आहे. +- जर यादीचा एकूण पेलोड 55 बाइट्सपेक्षा जास्त असेल, तर RLP एन्कोडिंगमध्ये **0xf7** अधिक पेलोडच्या लांबीच्या बायनरी स्वरूपाची बाइट्समधील लांबी हे मूल्य असलेला एक बाइट असतो, त्यानंतर पेलोडची लांबी, आणि त्यानंतर आयटमच्या RLP एन्कोडिंगचे एकत्रीकरण असते. पहिल्या बाइटची रेंज `[0xf8, 0xff]` (दशांश `[248, 255]`) आहे. + +कोडमध्ये, हे असे आहे: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## उदाहरणे {#examples} + +- "dog" ही स्ट्रिंग = [ 0x83, 'd', 'o', 'g' ] +- [ "cat", "dog" ] ही यादी = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- रिकामी स्ट्रिंग ('null') = `[ 0x80 ]` +- रिकामी यादी = `[ 0xc0 ]` +- पूर्णांक 0 = `[ 0x80 ]` +- बाइट '\\x00' = `[ 0x00 ]` +- बाइट '\\x0f' = `[ 0x0f ]` +- बाइट्स '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- तीनचे [संच सैद्धांतिक प्रतिनिधित्व](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers), `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- "Lorem ipsum dolor sit amet, consectetur adipisicing elit" ही स्ट्रिंग = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` , 'e', 'l', 'i', 't' ]` + +## RLP डीकोडिंग {#rlp-decoding} + +RLP एन्कोडिंगच्या नियमांनुसार आणि प्रक्रियेनुसार, RLP डीकोडचे इनपुट बायनरी डेटाचा अॅरे म्हणून मानले जाते. RLP डीकोडिंग प्रक्रिया खालीलप्रमाणे आहे: + +1. इनपुट डेटाच्या पहिल्या बाइटनुसार (म्हणजे, प्रीफिक्स) डेटा प्रकार, प्रत्यक्ष डेटाची लांबी आणि ऑफसेट डीकोड करणे; + +2. डेटाच्या प्रकार आणि ऑफसेटनुसार डेटा डीकोड करणे, धन पूर्णांकांसाठी किमान एन्कोडिंग नियमाचा आदर राखून; + +3. उर्वरित इनपुट डीकोड करणे सुरू ठेवणे; + +त्यापैकी, डेटा प्रकार आणि ऑफसेट डीकोड करण्याचे नियम खालीलप्रमाणे आहेत: + +1. जर पहिल्या बाइटची (म्हणजे, प्रीफिक्स) रेंज [0x00, 0x7f] असेल, तर डेटा एक स्ट्रिंग आहे आणि स्ट्रिंग हा तो पहिला बाइटच असतो; + +2. जर पहिल्या बाइटची रेंज [0x80, 0xb7] असेल, तर डेटा एक स्ट्रिंग आहे, आणि ज्याची लांबी पहिल्या बाइट वजा 0x80 इतकी आहे अशी स्ट्रिंग पहिल्या बाइटनंतर येते; + +3. जर पहिल्या बाइटची रेंज [0xb8, 0xbf] असेल, तर डेटा एक स्ट्रिंग आहे, आणि ज्याची बाइट्समधील लांबी पहिल्या बाइट वजा 0xb7 इतकी आहे अशी स्ट्रिंगची लांबी पहिल्या बाइटनंतर येते, आणि स्ट्रिंग त्या लांबीनंतर येते; + +4. जर पहिल्या बाइटची रेंज [0xc0, 0xf7] असेल, तर डेटा एक यादी आहे, आणि ज्या यादीचा एकूण पेलोड पहिल्या बाइट वजा 0xc0 इतका आहे, तिच्या सर्व आयटमच्या RLP एन्कोडिंगचे एकत्रीकरण पहिल्या बाइटनंतर येते; + +5. जर पहिल्या बाइटची रेंज [0xf8, 0xff] असेल, तर डेटा एक यादी आहे, आणि ज्याची लांबी पहिल्या बाइट वजा 0xf7 इतकी आहे असा यादीचा एकूण पेलोड पहिल्या बाइटनंतर येतो, आणि यादीच्या सर्व आयटमच्या RLP एन्कोडिंगचे एकत्रीकरण यादीच्या एकूण पेलोडनंतर येते; + +कोडमध्ये, हे असे आहे: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## पुढील वाचन {#further-reading} + +- [Ethereum मधील RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum अंडर द हूड: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- Coglio, A. (2020). ACL2 मधील Ethereum चा रिकर्सिव्ह लेंग्थ प्रीफिक्स. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## संबंधित विषय {#related-topics} + +- [पॅट्रिशिया मर्केल ट्राय](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/mr/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/mr/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..33130a7a662 --- /dev/null +++ b/public/content/translations/mr/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,149 @@ +--- +title: "सिंपल सिरीअलाइझ" +description: "Ethereum च्या SSZ फॉरमॅटचे स्पष्टीकरण." +lang: mr +sidebarDepth: 2 +--- + +**सिंपल सिरीअलाइझ (SSZ)** ही बीकन चेनवर वापरली जाणारी सिरीअलायझेशन पद्धत आहे. हे, पीअर डिस्कव्हरी प्रोटोकॉल वगळता, कन्सेंसस लेयरवर सर्वत्र एक्झिक्यूशन लेयरवर वापरल्या जाणार्‍या RLP सिरीअलायझेशनची जागा घेते. RLP सिरीअलायझेशनबद्दल अधिक जाणून घेण्यासाठी, [रिकर्सिव्ह-लेंग्थ प्रीफिक्स (RLP)](/developers/docs/data-structures-and-encoding/rlp/) पहा. SSZ डिटर्मिनिस्टिक असण्यासाठी आणि कार्यक्षमतेने मर्केलाइझ करण्यासाठी डिझाइन केलेले आहे. SSZ मध्ये दोन घटक आहेत असे मानले जाऊ शकते: एक सिरीअलायझेशन स्कीम आणि एक मर्केलायझेशन स्कीम जी सिरीअलाइझ केलेल्या डेटा स्ट्रक्चरसह कार्यक्षमतेने काम करण्यासाठी डिझाइन केलेली आहे. + +## SSZ कसे काम करते? {#how-does-ssz-work} + +### सिरीअलायझेशन {#serialization} + +SSZ ही एक सिरीअलायझेशन स्कीम आहे जी स्वयं-वर्णन करणारी नाही - उलट ती एका स्कीमावर अवलंबून असते जी आगाऊ माहित असणे आवश्यक आहे. SSZ सिरीअलायझेशनचे ध्येय म्हणजे कोणत्याही जटिलतेच्या ऑब्जेक्ट्सना बाइट्सच्या स्ट्रिंगच्या रूपात दर्शवणे. "बेसिक टाइप्स" साठी ही एक अतिशय सोपी प्रक्रिया आहे. घटकाला फक्त हेक्साडेसिमल बाइट्समध्ये रूपांतरित केले जाते. बेसिक टाइप्समध्ये यांचा समावेश आहे: + +- अनसाईन्ड इंटिजर्स +- बूलियन्स + +जटिल "कंपोझिट" प्रकारांसाठी, सिरीअलायझेशन अधिक क्लिष्ट आहे कारण कंपोझिट प्रकारात अनेक घटक असतात जे भिन्न प्रकार किंवा भिन्न आकाराचे किंवा दोन्ही असू शकतात. जेव्हा या सर्व ऑब्जेक्ट्सची लांबी निश्चित असते (म्हणजे, घटकांचा आकार त्यांच्या वास्तविक मूल्यांकडे दुर्लक्ष करून नेहमी स्थिर असतो) तेव्हा सिरीअलायझेशन म्हणजे कंपोझिट प्रकारातील प्रत्येक घटकाचे लिट्ल-एंडियन बाईटस्ट्रिंगमध्ये रूपांतरण करणे होय. हे बाईटस्ट्रिंग्स एकत्र जोडले जातात. सिरीअलाइझ केलेल्या ऑब्जेक्टमध्ये निश्चित-लांबीच्या घटकांचे बाईटलिस्ट रिप्रेझेंटेशन त्याच क्रमाने असते ज्या क्रमाने ते डीसिरीअलाइझ केलेल्या ऑब्जेक्टमध्ये दिसतात. + +व्हेरिएबल लांबीच्या प्रकारांसाठी, सिरीअलाइझ केलेल्या ऑब्जेक्टमधील त्या घटकाच्या स्थितीत प्रत्यक्ष डेटाला "ऑफसेट" मूल्याने बदलले जाते. प्रत्यक्ष डेटा सिरीअलाइझ केलेल्या ऑब्जेक्टच्या शेवटी एका हीपमध्ये जोडला जातो. ऑफसेट व्हॅल्यू हीपमधील प्रत्यक्ष डेटाच्या सुरूवातीसाठी इंडेक्स आहे, जो संबंधित बाइट्ससाठी पॉईंटर म्हणून काम करतो. + +खालील उदाहरण स्पष्ट करते की निश्चित आणि व्हेरिएबल-लांबीच्या दोन्ही घटकांसह कंटेनरसाठी ऑफसेटिंग कसे कार्य करते: + +```Rust + + struct Dummy { + + number1: u64, + number2: u64, + vector: Vec, + number3: u64 + } + + dummy = Dummy{ + + number1: 37, + number2: 55, + vector: vec![1,2,3,4], + number3: 22, + } + + serialized = ssz.serialize(dummy) + +``` + +`serialized` ची रचना खालीलप्रमाणे असेल (येथे फक्त 4 बिट्सपर्यंत पॅड केलेले आहे, प्रत्यक्षात 32 बिट्सपर्यंत पॅड केलेले आहे आणि स्पष्टतेसाठी `int` रिप्रेझेंटेशन ठेवले आहे): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + नंबर1 नंबर2 वेक्टरसाठी नंबर 3 वेक्टरचे + ऑफसेट मूल्य + +``` + +स्पष्टतेसाठी ओळींमध्ये विभागलेले: + +``` +[ + 37, 0, 0, 0, # `number1` चे लिट्ल-एंडियन एन्कोडिंग. + 55, 0, 0, 0, # `number2` चे लिट्ल-एंडियन एन्कोडिंग. + 16, 0, 0, 0, # `vector` चे मूल्य कोठे सुरू होते हे दर्शवणारा "ऑफसेट" (लिट्ल-एंडियन 16). + 22, 0, 0, 0, # `number3` चे लिट्ल-एंडियन एन्कोडिंग. + 1, 2, 3, 4, # `vector` मधील वास्तविक मूल्ये. +] +``` + +हे अजूनही एक सरलीकरण आहे - वरील स्कीमाटिक्समधील इंटिजर्स आणि शून्य प्रत्यक्षात बाईटलिस्ट म्हणून संग्रहित केले जातील, याप्रमाणे: + +``` +[ + 10100101000000000000000000000000 # `number1` चे लिट्ल-एंडियन एन्कोडिंग + 10110111000000000000000000000000 # `number2` चे लिट्ल-एंडियन एन्कोडिंग. + 10010000000000000000000000000000 # `vector` चे मूल्य कोठे सुरू होते हे दर्शवणारा "ऑफसेट" (लिट्ल-एंडियन 16). + 10010110000000000000000000000000 # `number3` चे लिट्ल-एंडियन एन्कोडिंग. + 10000001100000101000001110000100 # `bytes` फील्डचे वास्तविक मूल्य. +] +``` + +त्यामुळे व्हेरिएबल-लांबीच्या प्रकारांसाठी वास्तविक मूल्ये सिरीअलाइझ केलेल्या ऑब्जेक्टच्या शेवटी एका हीपमध्ये संग्रहित केली जातात आणि त्यांचे ऑफसेट फील्डच्या क्रमबद्ध सूचीमध्ये त्यांच्या योग्य स्थानांवर संग्रहित केले जातात. + +`BitList` प्रकारासारखी काही विशेष प्रकरणे देखील आहेत ज्यांना विशिष्ट हाताळणीची आवश्यकता असते, ज्यासाठी सिरीअलायझेशन दरम्यान लांबी कॅप जोडणे आणि डीसिरीअलायझेशन दरम्यान काढून टाकणे आवश्यक असते. संपूर्ण तपशील [SSZ स्पेक](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) मध्ये उपलब्ध आहेत. + +### डीसिरीअलायझेशन {#deserialization} + +या ऑब्जेक्टला डीसिरीअलाइझ करण्यासाठी स्कीमा आवश्यक आहे. स्कीमा सिरीअलाइझ केलेल्या डेटाचा अचूक लेआउट परिभाषित करतो जेणेकरून प्रत्येक विशिष्ट घटक बाइट्सच्या ब्लॉबमधून काही अर्थपूर्ण ऑब्जेक्टमध्ये डीसिरीअलाइझ केला जाऊ शकतो, ज्यामध्ये घटकांचा योग्य प्रकार, मूल्य, आकार आणि स्थान असेल. स्कीमाच डीसिरीअलायझरला सांगते की कोणती मूल्ये वास्तविक मूल्ये आहेत आणि कोणती ऑफसेट आहेत. जेव्हा एखादे ऑब्जेक्ट सिरीअलाइझ केले जाते तेव्हा सर्व फील्ड नावे अदृश्य होतात, परंतु स्कीमानुसार डीसिरीअलायझेशनवर पुन्हा इन्स्टंटिएट केली जातात. + +यावरील इंटरॅक्टिव्ह स्पष्टीकरणासाठी [ssz.dev](https://www.ssz.dev/overview) पहा. + +## मर्केलायझेशन {#merkleization} + +या SSZ सिरीअलाइझ केलेल्या ऑब्जेक्टला नंतर मर्केलाइझ केले जाऊ शकते - म्हणजेच त्याच डेटाच्या मर्केल-ट्री रिप्रेझेंटेशनमध्ये रूपांतरित केले जाऊ शकते. प्रथम, सिरीअलाइझ केलेल्या ऑब्जेक्टमधील 32-बाइट चंक्सची संख्या निश्चित केली जाते. ही ट्रीची "लीव्हज" (पाने) आहेत. लीव्हजची एकूण संख्या 2 च्या घातांकात असणे आवश्यक आहे जेणेकरून लीव्हज एकत्र हॅश केल्यावर शेवटी एकच हॅश-ट्री-रूट तयार होईल. जर नैसर्गिकरित्या असे नसेल, तर 32 बाइट शून्य असलेली अतिरिक्त लीव्हज जोडली जातात. रेखाचित्रानुसार: + +``` + हॅश ट्री रूट + / \ + / \ + / \ + / \ + लीव्हज 1 आणि 2 चा हॅश लीव्हज 3 आणि 4 चा हॅश + / \ / \ + / \ / \ + / \ / \ + लीफ1 लीफ2 लीफ3 लीफ4 +``` + +अशी काही प्रकरणे देखील आहेत जिथे ट्रीची लीव्हज वरील उदाहरणाप्रमाणे नैसर्गिकरित्या समान रीतीने वितरीत होत नाहीत. उदाहरणार्थ, लीफ 4 हे अनेक घटकांसह एक कंटेनर असू शकते ज्यासाठी मर्केल ट्रीमध्ये अतिरिक्त "डेप्थ" (खोली) जोडण्याची आवश्यकता असते, ज्यामुळे एक असमान ट्री तयार होते. + +या ट्री घटकांना लीफ X, नोड X इत्यादी म्हणून संबोधण्याऐवजी, आपण त्यांना सामान्यीकृत इंडेक्स देऊ शकतो, ज्याची सुरुवात रूट = 1 पासून होते आणि प्रत्येक स्तरावर डावीकडून उजवीकडे मोजणी केली जाते. हा वर स्पष्ट केलेला सामान्यीकृत इंडेक्स आहे. सिरीअलाइझ केलेल्या सूचीतील प्रत्येक घटकाचा एक सामान्यीकृत इंडेक्स `2**depth + idx` च्या बरोबर असतो, जिथे idx हे सिरीअलाइझ केलेल्या ऑब्जेक्टमधील त्याचे शून्य-इंडेक्स केलेले स्थान आहे आणि डेप्थ (खोली) मर्केल ट्रीमधील स्तरांची संख्या आहे, जी घटकांच्या (लीव्हज) संख्येचा बेस-टू लॉगरिथम म्हणून निर्धारित केली जाऊ शकते. + +## सामान्यीकृत इंडेक्स {#generalized-indices} + +सामान्यीकृत इंडेक्स हा एक इंटिजर आहे जो बायनरी मर्केल ट्रीमधील नोडचे प्रतिनिधित्व करतो जिथे प्रत्येक नोडचा सामान्यीकृत इंडेक्स `2 ** depth + index in row` असतो. + +``` + 1 --डेप्थ = 0 2**0 + 0 = 1 + 2 3 --डेप्थ = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --डेप्थ = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +हे रिप्रेझेंटेशन मर्केल ट्रीमधील डेटाच्या प्रत्येक भागासाठी एक नोड इंडेक्स देते. + +## मल्टीप्रूफ्स {#multiproofs} + +एका विशिष्ट घटकाचे प्रतिनिधित्व करणाऱ्या सामान्यीकृत इंडेक्सची सूची प्रदान केल्याने आम्हाला ते हॅश-ट्री-रूट विरुद्ध सत्यापित करण्याची परवानगी मिळते. हे रूट म्हणजे वास्तवाची आपली स्वीकारलेली आवृत्ती आहे. आपल्याला प्रदान केलेला कोणताही डेटा त्या वास्तवाविरुद्ध मर्केल ट्रीमध्ये योग्य ठिकाणी (त्याच्या सामान्यीकृत इंडेक्सद्वारे निर्धारित) घालून आणि रूट स्थिर राहतो हे पाहून सत्यापित केला जाऊ शकतो. [येथे](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) स्पेक्समध्ये अशी फंक्शन्स आहेत जी सामान्यीकृत इंडेक्सच्या विशिष्ट सेटमधील सामग्री सत्यापित करण्यासाठी आवश्यक असलेल्या नोड्सचा किमान संच कसा मोजावा हे दर्शवतात. + +उदाहरणार्थ, खालील ट्रीमधील इंडेक्स 9 मधील डेटा सत्यापित करण्यासाठी, आम्हाला इंडेक्स 8, 9, 5, 3, 1 वरील डेटाचा हॅश आवश्यक आहे. +(8,9) चा हॅश (4) च्या हॅशच्या बरोबर असावा, जो 5 सोबत हॅश होऊन 2 तयार करतो, जो 3 सोबत हॅश होऊन ट्री रूट 1 तयार करतो. जर 9 साठी चुकीचा डेटा प्रदान केला गेला, तर रूट बदलेल - आम्ही हे ओळखू आणि ब्रांच सत्यापित करण्यात अयशस्वी होऊ. + +``` +* = प्रूफ तयार करण्यासाठी आवश्यक डेटा + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## पुढील वाचन {#further-reading} + +- [Ethereum अपग्रेड करणे: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Ethereum अपग्रेड करणे: मर्केलायझेशन](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ अंमलबजावणी](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ कॅल्क्युलेटर](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/)