---
title: "ब्लॉक्स"
description: "इथेरियम ब्लॉकचेनमधील ब्लॉक्सचा आढावा – त्यांची डेटा रचना, त्यांची आवश्यकता का आहे आणि ते कसे बनवले जातात."
lang: mr
---

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

## पूर्वतयारी {#prerequisites}

ब्लॉक्स हा नवशिक्यांसाठी अतिशय सोपा विषय आहे. परंतु हे पृष्ठ अधिक चांगल्या प्रकारे समजून घेण्यासाठी, आम्ही शिफारस करतो की तुम्ही प्रथम [खाती](/developers/docs/accounts/), [व्यवहार](/developers/docs/transactions/), आणि आमची [इथेरियमची ओळख](/developers/docs/intro-to-ethereum/) वाचावी.

## ब्लॉक्स का? {#why-blocks}

[इथेरियम](/) नेटवर्कवरील सर्व सहभागींनी एक समक्रमित (synchronized) स्थिती राखली आहे आणि व्यवहारांच्या अचूक इतिहासावर त्यांचे एकमत आहे हे सुनिश्चित करण्यासाठी, आम्ही व्यवहारांना ब्लॉक्समध्ये गटबद्ध करतो. याचा अर्थ डझनभर (किंवा शेकडो) व्यवहारांची बांधिलकी (committed), एकमत आणि समक्रमण एकाच वेळी केले जाते.

![A diagram showing transaction in a block causing state changes](./tx-block.png)
_[Ethereum EVM illustrated](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf) वरून रूपांतरित केलेली आकृती_

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

## ब्लॉक्स कसे काम करतात {#how-blocks-work}

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

एकदा नेटवर्कवरील यादृच्छिकपणे (randomly) निवडलेल्या प्रमाणकाद्वारे ब्लॉक एकत्र केला की, तो उर्वरित नेटवर्कवर प्रसारित केला जातो; सर्व नोड्स हा ब्लॉक त्यांच्या ब्लॉकचेनच्या शेवटी जोडतात, आणि पुढील ब्लॉक तयार करण्यासाठी नवीन प्रमाणक निवडला जातो. अचूक ब्लॉक-असेंब्ली प्रक्रिया आणि कमिटमेंट/एकमत प्रक्रिया सध्या इथेरियमच्या “प्रूफ-ऑफ-स्टेक (PoS)” प्रोटोकॉलद्वारे निर्दिष्ट केली आहे.

## प्रूफ-ऑफ-स्टेक प्रोटोकॉल {#proof-of-stake-protocol}

प्रूफ-ऑफ-स्टेकचा अर्थ खालीलप्रमाणे आहे:

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

[प्रूफ-ऑफ-स्टेक बद्दल अधिक](/developers/docs/consensus-mechanisms/pos)

## ब्लॉकमध्ये काय असते? {#block-anatomy}

ब्लॉकमध्ये बरीच माहिती समाविष्ट असते. सर्वोच्च स्तरावर ब्लॉकमध्ये खालील फील्ड्स असतात:

| फील्ड | वर्णन |
| :--------------- | :---------------------------------------------------- |
| `slot` | ब्लॉक ज्या स्लॉटचा आहे तो स्लॉट |
| `proposer_index` | ब्लॉक प्रस्तावित करणाऱ्या प्रमाणकाचा ID |
| `parent_root` | मागील ब्लॉकचा हॅश |
| `state_root` | स्थिती ऑब्जेक्टचा रूट हॅश |
| `body` | खाली परिभाषित केल्याप्रमाणे अनेक फील्ड्स असलेला ऑब्जेक्ट |

ब्लॉक `body` मध्ये स्वतःचे अनेक फील्ड्स असतात:

| फील्ड | वर्णन |
| :------------------- | :----------------------------------------------- |
| `randao_reveal` | पुढील ब्लॉक प्रस्तावक निवडण्यासाठी वापरलेले मूल्य |
| `eth1_data` | ठेव कराराबद्दल माहिती |
| `graffiti` | ब्लॉक्स टॅग करण्यासाठी वापरलेला अनियंत्रित (arbitrary) डेटा |
| `proposer_slashings` | स्लॅशिंग होणाऱ्या प्रमाणकांची यादी |
| `attester_slashings` | स्लॅशिंग होणाऱ्या साक्षांकनकर्त्यांची (attesters) यादी |
| `attestations` | मागील स्लॉट्सच्या विरूद्ध केलेल्या साक्षांकनांची यादी |
| `deposits` | ठेव करारामध्ये नवीन ठेवींची यादी |
| `voluntary_exits` | नेटवर्कमधून बाहेर पडणाऱ्या प्रमाणकांची यादी |
| `sync_aggregate` | लाईट क्लायंट्सना सेवा देण्यासाठी वापरल्या जाणाऱ्या प्रमाणकांचा उपसंच |
| `execution_payload` | अंमलबजावणी क्लायंटकडून पास केलेले व्यवहार |

`attestations` फील्डमध्ये ब्लॉकमधील सर्व साक्षांकनांची यादी असते. साक्षांकनांचा स्वतःचा डेटा प्रकार असतो ज्यामध्ये डेटाचे अनेक भाग असतात. प्रत्येक साक्षांकनामध्ये हे असते:

| फील्ड | वर्णन |
| :----------------- | :------------------------------------------------------------- |
| `aggregation_bits` | या साक्षांकनात कोणत्या प्रमाणकांनी भाग घेतला याची यादी |
| `data` | एकाधिक उपफील्ड्स (subfields) असलेला कंटेनर |
| `signature` | `data` भागाच्या विरूद्ध प्रमाणकांच्या संचाची एकत्रित स्वाक्षरी |

`attestation` मधील `data` फील्डमध्ये खालील गोष्टी असतात:

| फील्ड | वर्णन |
| :------------------ | :-------------------------------------------------------------- |
| `slot` | साक्षांकनाशी संबंधित असलेला स्लॉट |
| `index` | साक्षांकन करणाऱ्या प्रमाणकांसाठी निर्देशांक |
| `beacon_block_root` | चेनचे हेड म्हणून पाहिलेल्या बीकन ब्लॉकचा रूट हॅश |
| `source` | शेवटचा प्रमाणित चेकपॉईंट |
| `target` | नवीनतम पर्व (epoch) सीमा ब्लॉक |

`execution_payload` मधील व्यवहारांची अंमलबजावणी केल्याने जागतिक स्थिती अद्यतनित होते. नवीन स्थिती नवीन ब्लॉकच्या `state_root` फील्डशी जुळते याची खात्री करण्यासाठी सर्व क्लायंट्स `execution_payload` मधील व्यवहारांची पुन्हा अंमलबजावणी करतात. अशा प्रकारे क्लायंट्स सांगू शकतात की नवीन ब्लॉक वैध आहे आणि त्यांच्या ब्लॉकचेनमध्ये जोडण्यासाठी सुरक्षित आहे. `execution payload` स्वतः अनेक फील्ड्स असलेला एक ऑब्जेक्ट आहे. एक `execution_payload_header` देखील आहे ज्यामध्ये अंमलबजावणी डेटाबद्दल महत्त्वाची सारांश माहिती असते. या डेटा संरचना खालीलप्रमाणे आयोजित केल्या आहेत:

`execution_payload_header` मध्ये खालील फील्ड्स असतात:

| फील्ड | वर्णन |
| :------------------ | :------------------------------------------------------------------ |
| `parent_hash` | मूळ (parent) ब्लॉकचा हॅश |
| `fee_recipient` | व्यवहार शुल्क भरण्यासाठी खात्याचा पत्ता |
| `state_root` | या ब्लॉकमधील बदल लागू केल्यानंतर जागतिक स्थितीसाठी रूट हॅश |
| `receipts_root` | व्यवहार पावत्यांच्या (receipts) ट्रायचा (trie) हॅश |
| `logs_bloom` | घटना (event) लॉग्स असलेली डेटा संरचना |
| `prev_randao` | यादृच्छिक प्रमाणक निवडीमध्ये वापरलेले मूल्य |
| `block_number` | वर्तमान ब्लॉकचा क्रमांक |
| `gas_limit` | या ब्लॉकमध्ये अनुमत असलेली कमाल गॅस मर्यादा |
| `gas_used` | या ब्लॉकमध्ये वापरलेल्या गॅसचे प्रत्यक्ष प्रमाण |
| `timestamp` | ब्लॉक वेळ |
| `extra_data` | रॉ बाइट्स (raw bytes) म्हणून अनियंत्रित अतिरिक्त डेटा |
| `base_fee_per_gas` | पायाभूत शुल्क मूल्य |
| `block_hash` | अंमलबजावणी ब्लॉकचा हॅश |
| `transactions_root` | पेलोडमधील व्यवहारांचा रूट हॅश |
| `withdrawal_root` | पेलोडमधील रक्कम काढण्याच्या (withdrawals) क्रियांचा रूट हॅश |

`execution_payload` मध्ये स्वतः खालील गोष्टी असतात (लक्षात घ्या की हे हेडरसारखेच आहे, फक्त व्यवहारांच्या रूट हॅशऐवजी यात व्यवहारांची प्रत्यक्ष यादी आणि रक्कम काढण्याची माहिती समाविष्ट आहे):

| फील्ड | वर्णन |
| :----------------- | :------------------------------------------------------------------ |
| `parent_hash` | मूळ ब्लॉकचा हॅश |
| `fee_recipient` | व्यवहार शुल्क भरण्यासाठी खात्याचा पत्ता |
| `state_root` | या ब्लॉकमधील बदल लागू केल्यानंतर जागतिक स्थितीसाठी रूट हॅश |
| `receipts_root` | व्यवहार पावत्यांच्या ट्रायचा हॅश |
| `logs_bloom` | घटना लॉग्स असलेली डेटा संरचना |
| `prev_randao` | यादृच्छिक प्रमाणक निवडीमध्ये वापरलेले मूल्य |
| `block_number` | वर्तमान ब्लॉकचा क्रमांक |
| `gas_limit` | या ब्लॉकमध्ये अनुमत असलेली कमाल गॅस मर्यादा |
| `gas_used` | या ब्लॉकमध्ये वापरलेल्या गॅसचे प्रत्यक्ष प्रमाण |
| `timestamp` | ब्लॉक वेळ |
| `extra_data` | रॉ बाइट्स म्हणून अनियंत्रित अतिरिक्त डेटा |
| `base_fee_per_gas` | पायाभूत शुल्क मूल्य |
| `block_hash` | अंमलबजावणी ब्लॉकचा हॅश |
| `transactions` | अंमलबजावणी करावयाच्या व्यवहारांची यादी |
| `withdrawals` | रक्कम काढण्याच्या (withdrawal) ऑब्जेक्ट्सची यादी |

`withdrawals` यादीमध्ये खालील प्रकारे संरचित केलेले `withdrawal` ऑब्जेक्ट्स असतात:

| फील्ड | वर्णन |
| :--------------- | :--------------------------------- |
| `address` | रक्कम काढलेल्या खात्याचा पत्ता |
| `amount` | काढलेली रक्कम |
| `index` | रक्कम काढण्याचे निर्देशांक मूल्य |
| `validatorIndex` | प्रमाणक निर्देशांक मूल्य |

## ब्लॉक वेळ {#block-time}

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

ही अंमलबजावणी प्रूफ-ऑफ-वर्क (PoW) आधारित प्रणालींपेक्षा वेगळी आहे जिथे ब्लॉक वेळा संभाव्य (probabilistic) असतात आणि प्रोटोकॉलच्या लक्ष्यित खनन काठिण्यानुसार (mining difficulty) ट्यून केल्या जातात. इथेरियमची [सरासरी ब्लॉक वेळ](https://etherscan.io/chart/blocktime) हे याचे एक उत्तम उदाहरण आहे ज्याद्वारे नवीन 12s ब्लॉक वेळेच्या सुसंगततेवर आधारित प्रूफ-ऑफ-वर्क वरून प्रूफ-ऑफ-स्टेक मधील संक्रमण स्पष्टपणे अनुमानित केले जाऊ शकते.

## ब्लॉक आकार {#block-size}

एक अंतिम महत्त्वाची नोंद म्हणजे ब्लॉक्स स्वतः आकारात मर्यादित असतात. प्रत्येक ब्लॉकचा लक्ष्यित आकार 30 दशलक्ष गॅस असतो परंतु नेटवर्कच्या मागणीनुसार ब्लॉक्सचा आकार वाढेल किंवा कमी होईल, जो 60 दशलक्ष गॅसच्या (लक्ष्यित ब्लॉक आकाराच्या 2x) ब्लॉक मर्यादेपर्यंत असू शकतो. ब्लॉक गॅस मर्यादा मागील ब्लॉकच्या गॅस मर्यादेवरून 1/1024 च्या पटीने वर किंवा खाली समायोजित केली जाऊ शकते. परिणामी, प्रमाणक एकमताने ब्लॉक गॅस मर्यादा बदलू शकतात. ब्लॉकमधील सर्व व्यवहारांद्वारे खर्च केलेल्या गॅसचे एकूण प्रमाण ब्लॉक गॅस मर्यादेपेक्षा कमी असणे आवश्यक आहे. हे महत्त्वाचे आहे कारण हे सुनिश्चित करते की ब्लॉक्स अनियंत्रितपणे मोठे असू शकत नाहीत. जर ब्लॉक्स अनियंत्रितपणे मोठे असू शकले असते, तर कमी कार्यक्षम फुल नोड्स जागा आणि गतीच्या आवश्यकतांमुळे नेटवर्कशी जुळवून घेण्यास हळूहळू असमर्थ ठरले असते. ब्लॉक जितका मोठा असेल, तितकी पुढील स्लॉटसाठी वेळेत त्यावर प्रक्रिया करण्यासाठी अधिक संगणकीय शक्ती (computing power) आवश्यक असेल. हे एक केंद्रीकरण करणारे बल (centralizing force) आहे, ज्याला ब्लॉक आकारांवर मर्यादा घालून विरोध केला जातो.

## पुढील वाचन {#further-reading}

_तुम्हाला मदत करणाऱ्या एखाद्या समुदाय संसाधनाबद्दल माहिती आहे का? हे पृष्ठ संपादित करा आणि ते जोडा!_

## संबंधित विषय {#related-topics}

- [व्यवहार](/developers/docs/transactions/)
- [गॅस](/developers/docs/gas/)
- [प्रूफ-ऑफ-स्टेक](/developers/docs/consensus-mechanisms/pos)

<QuizWidget quizKey="blocks" />