---
title: "بلاک"
description: "ایتھیریم بلاک چین میں بلاکس کا جائزہ – ان کا ڈیٹا اسٹرکچر، ان کی ضرورت کیوں ہے، اور وہ کیسے بنائے جاتے ہیں۔"
lang: ur
---

بلاکس ٹرانزیکشنز کے بیچز ہوتے ہیں جن میں چین کے پچھلے بلاک کا ہیش شامل ہوتا ہے۔ یہ بلاکس کو ایک ساتھ (ایک چین میں) جوڑتا ہے کیونکہ ہیشز کو بلاک کے ڈیٹا سے کرپٹوگرافک طریقے سے اخذ کیا جاتا ہے۔ یہ دھوکہ دہی کو روکتا ہے، کیونکہ تاریخ میں کسی بھی بلاک میں ایک تبدیلی آنے والے تمام بلاکس کو باطل کر دے گی کیونکہ اس کے بعد کے تمام ہیشز بدل جائیں گے اور بلاک چین چلانے والے ہر شخص کو اس کا علم ہو جائے گا۔

## پیشگی شرائط {#prerequisites}

بلاکس ایک بہت ہی ابتدائی سطح کا موضوع ہے۔ لیکن اس صفحے کو بہتر طور پر سمجھنے میں آپ کی مدد کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [اکاؤنٹس](/developers/docs/accounts/)، [ٹرانزیکشنز](/developers/docs/transactions/)، اور ہمارا [ایتھیریم کا تعارف](/developers/docs/intro-to-ethereum/) پڑھیں۔

## بلاکس کیوں؟ {#why-blocks}

اس بات کو یقینی بنانے کے لیے کہ [ایتھیریم](/) نیٹ ورک پر تمام شرکاء ایک ہم آہنگ حالت کو برقرار رکھیں اور ٹرانزیکشنز کی درست تاریخ پر اتفاق رائے کریں، ہم ٹرانزیکشنز کو بلاکس میں بیچ کرتے ہیں۔ اس کا مطلب ہے کہ درجنوں (یا سینکڑوں) ٹرانزیکشنز ایک ہی وقت میں کمٹ، متفق، اور ہم آہنگ کی جاتی ہیں۔

![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}

ٹرانزیکشن کی تاریخ کو محفوظ رکھنے کے لیے، بلاکس کو سختی سے ترتیب دیا جاتا ہے (ہر نیا بنایا گیا بلاک اپنے پیرنٹ بلاک کا حوالہ رکھتا ہے)، اور بلاکس کے اندر ٹرانزیکشنز کو بھی سختی سے ترتیب دیا جاتا ہے۔ شاذ و نادر صورتوں کے علاوہ، کسی بھی وقت، نیٹ ورک پر تمام شرکاء بلاکس کی صحیح تعداد اور تاریخ پر متفق ہوتے ہیں، اور موجودہ لائیو ٹرانزیکشن کی درخواستوں کو اگلے بلاک میں بیچ کرنے کے لیے کام کر رہے ہوتے ہیں۔

ایک بار جب نیٹ ورک پر تصادفی طور پر منتخب کردہ توثیق کار کے ذریعے بلاک تیار کر لیا جاتا ہے، تو اسے باقی نیٹ ورک میں پھیلا دیا جاتا ہے؛ تمام نوڈز اس بلاک کو اپنی بلاک چین کے آخر میں شامل کرتے ہیں، اور اگلا بلاک بنانے کے لیے ایک نیا توثیق کار منتخب کیا جاتا ہے۔ بلاک کو جمع کرنے کا درست عمل اور کمٹمنٹ/اتفاق رائے کا عمل فی الحال ایتھیریم کے "حصہ داری کا ثبوت (PoS)" پروٹوکول کے ذریعے متعین کیا گیا ہے۔

## حصہ داری کا ثبوت (PoS) پروٹوکول {#proof-of-stake-protocol}

حصہ داری کا ثبوت (PoS) کا مطلب درج ذیل ہے:

- توثیق کرنے والے نوڈز کو برے رویے کے خلاف ضمانت کے طور پر ڈپازٹ کنٹریکٹ میں <span dir="ltr">32 ETH</span> اسٹیک کرنا پڑتا ہے۔ اس سے نیٹ ورک کی حفاظت میں مدد ملتی ہے کیونکہ ثابت شدہ بے ایمانی کی سرگرمی اس اسٹیک کے کچھ یا تمام حصے کے تباہ ہونے کا سبب بنتی ہے۔
- ہر سلاٹ میں (بارہ سیکنڈ کے وقفے سے) ایک توثیق کار کو تصادفی طور پر بلاک تجویز کنندہ کے طور پر منتخب کیا جاتا ہے۔ وہ ٹرانزیکشنز کو ایک ساتھ بنڈل کرتے ہیں، انہیں ایگزیکیوٹ کرتے ہیں اور ایک نئی 'حالت' کا تعین کرتے ہیں۔ وہ اس معلومات کو ایک بلاک میں لپیٹتے ہیں اور اسے دوسرے توثیق کاروں تک پہنچاتے ہیں۔
- دوسرے توثیق کار جو نئے بلاک کے بارے میں سنتے ہیں وہ ٹرانزیکشنز کو دوبارہ ایگزیکیوٹ کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ وہ عالمی حالت میں مجوزہ تبدیلی سے متفق ہیں۔ یہ فرض کرتے ہوئے کہ بلاک درست ہے، وہ اسے اپنے ڈیٹا بیس میں شامل کر لیتے ہیں۔
- اگر کوئی توثیق کار ایک ہی سلاٹ کے لیے دو متصادم بلاکس کے بارے میں سنتا ہے تو وہ اپنے فورک-چوائس الگورتھم کا استعمال کرتے ہوئے اس کا انتخاب کرتے ہیں جسے سب سے زیادہ اسٹیک کیے گئے <span dir="ltr">ETH</span> کی حمایت حاصل ہو۔

[حصہ داری کا ثبوت (PoS) کے بارے میں مزید](/developers/docs/consensus-mechanisms/pos)

## بلاک میں کیا ہوتا ہے؟ {#block-anatomy}

ایک بلاک کے اندر بہت سی معلومات موجود ہوتی ہیں۔ اعلیٰ ترین سطح پر ایک بلاک میں درج ذیل فیلڈز شامل ہوتی ہیں:

| فیلڈ | تفصیل |
| :--------------- | :---------------------------------------------------- |
| `slot` | وہ سلاٹ جس سے بلاک تعلق رکھتا ہے |
| `proposer_index` | بلاک تجویز کرنے والے توثیق کار کی ID |
| `parent_root` | پچھلے بلاک کا ہیش |
| `state_root` | حالت آبجیکٹ کا روٹ ہیش |
| `body` | ایک آبجیکٹ جس میں کئی فیلڈز شامل ہیں، جیسا کہ ذیل میں بیان کیا گیا ہے |

بلاک `body` میں اس کی اپنی کئی فیلڈز شامل ہیں:

| فیلڈ | تفصیل |
| :------------------- | :----------------------------------------------- |
| `randao_reveal` | اگلے بلاک تجویز کنندہ کو منتخب کرنے کے لیے استعمال ہونے والی ویلیو |
| `eth1_data` | ڈپازٹ کنٹریکٹ کے بارے میں معلومات |
| `graffiti` | بلاکس کو ٹیگ کرنے کے لیے استعمال ہونے والا صوابدیدی ڈیٹا |
| `proposer_slashings` | کٹوتی کیے جانے والے توثیق کاروں کی فہرست |
| `attester_slashings` | کٹوتی کیے جانے والے تصدیق کنندگان کی فہرست |
| `attestations` | پچھلے سلاٹس کے خلاف کی گئی تصدیقات کی فہرست |
| `deposits` | ڈپازٹ کنٹریکٹ میں نئے ڈپازٹس کی فہرست |
| `voluntary_exits` | نیٹ ورک سے انخلا کرنے والے توثیق کاروں کی فہرست |
| `sync_aggregate` | لائٹ کلائنٹس کو سروس دینے کے لیے استعمال ہونے والے توثیق کاروں کا سب سیٹ |
| `execution_payload` | ایگزیکیوشن کلائنٹ سے پاس کی گئی ٹرانزیکشنز |

`attestations` فیلڈ میں بلاک میں موجود تمام تصدیقات کی فہرست ہوتی ہے۔ تصدیقات کی اپنی ڈیٹا ٹائپ ہوتی ہے جس میں ڈیٹا کے کئی حصے ہوتے ہیں۔ ہر تصدیق میں شامل ہوتا ہے:

| فیلڈ | تفصیل |
| :----------------- | :------------------------------------------------------------- |
| `aggregation_bits` | ایک فہرست کہ کن توثیق کاروں نے اس تصدیق میں حصہ لیا |
| `data` | متعدد ذیلی فیلڈز کے ساتھ ایک کنٹینر |
| `signature` | `data` حصے کے خلاف توثیق کاروں کے ایک سیٹ کے مجموعی دستخط |

`attestation` میں `data` فیلڈ میں درج ذیل شامل ہیں:

| فیلڈ | تفصیل |
| :------------------ | :-------------------------------------------------------------- |
| `slot` | وہ سلاٹ جس سے تصدیق کا تعلق ہے |
| `index` | تصدیق کرنے والے توثیق کاروں کے لیے اشاریے |
| `beacon_block_root` | بیکن بلاک کا روٹ ہیش جسے چین کے ہیڈ کے طور پر دیکھا جاتا ہے |
| `source` | آخری جواز یافتہ چیک پوائنٹ |
| `target` | تازہ ترین دور کی باؤنڈری کا بلاک |

`execution_payload` میں ٹرانزیکشنز کو ایگزیکیوٹ کرنے سے عالمی حالت اپ ڈیٹ ہو جاتی ہے۔ تمام کلائنٹس `execution_payload` میں ٹرانزیکشنز کو دوبارہ ایگزیکیوٹ کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ نئی حالت نئے بلاک کی `state_root` فیلڈ سے میل کھاتی ہے۔ اس طرح کلائنٹس بتا سکتے ہیں کہ ایک نیا بلاک درست ہے اور ان کی بلاک چین میں شامل کرنے کے لیے محفوظ ہے۔ `execution payload` بذات خود کئی فیلڈز کے ساتھ ایک آبجیکٹ ہے۔ ایک `execution_payload_header` بھی ہے جس میں ایگزیکیوشن ڈیٹا کے بارے میں اہم خلاصہ معلومات ہوتی ہیں۔ یہ ڈیٹا اسٹرکچرز درج ذیل کے طور پر منظم کیے گئے ہیں:

`execution_payload_header` میں درج ذیل فیلڈز شامل ہیں:

| فیلڈ | تفصیل |
| :------------------ | :------------------------------------------------------------------ |
| `parent_hash` | پیرنٹ بلاک کا ہیش |
| `fee_recipient` | ٹرانزیکشن فیس ادا کرنے کے لیے اکاؤنٹ کا پتہ |
| `state_root` | اس بلاک میں تبدیلیاں لاگو کرنے کے بعد عالمی حالت کا روٹ ہیش |
| `receipts_root` | ٹرانزیکشن کی رسیدوں کے ٹرائی (trie) کا ہیش |
| `logs_bloom` | ایونٹس لاگز پر مشتمل ڈیٹا اسٹرکچر |
| `prev_randao` | تصادفی توثیق کار کے انتخاب میں استعمال ہونے والی ویلیو |
| `block_number` | موجودہ بلاک کا نمبر |
| `gas_limit` | اس بلاک میں اجازت دی گئی زیادہ سے زیادہ گیس |
| `gas_used` | اس بلاک میں استعمال ہونے والی گیس کی اصل مقدار |
| `timestamp` | بلاک کا وقت |
| `extra_data` | خام بائٹس کے طور پر صوابدیدی اضافی ڈیٹا |
| `base_fee_per_gas` | بنیادی فیس کی ویلیو |
| `block_hash` | ایگزیکیوشن بلاک کا ہیش |
| `transactions_root` | پے لوڈ میں ٹرانزیکشنز کا روٹ ہیش |
| `withdrawal_root` | پے لوڈ میں انخلا کا روٹ ہیش |

`execution_payload` میں بذات خود درج ذیل شامل ہیں (غور کریں کہ یہ ہیڈر سے بالکل مماثل ہے سوائے اس کے کہ ٹرانزیکشنز کے روٹ ہیش کے بجائے اس میں ٹرانزیکشنز کی اصل فہرست اور انخلا کی معلومات شامل ہیں):

| فیلڈ | تفصیل |
| :----------------- | :------------------------------------------------------------------ |
| `parent_hash` | پیرنٹ بلاک کا ہیش |
| `fee_recipient` | ٹرانزیکشن فیس ادا کرنے کے لیے اکاؤنٹ کا پتہ |
| `state_root` | اس بلاک میں تبدیلیاں لاگو کرنے کے بعد عالمی حالت کا روٹ ہیش |
| `receipts_root` | ٹرانزیکشن کی رسیدوں کے ٹرائی (trie) کا ہیش |
| `logs_bloom` | ایونٹس لاگز پر مشتمل ڈیٹا اسٹرکچر |
| `prev_randao` | تصادفی توثیق کار کے انتخاب میں استعمال ہونے والی ویلیو |
| `block_number` | موجودہ بلاک کا نمبر |
| `gas_limit` | اس بلاک میں اجازت دی گئی زیادہ سے زیادہ گیس |
| `gas_used` | اس بلاک میں استعمال ہونے والی گیس کی اصل مقدار |
| `timestamp` | بلاک کا وقت |
| `extra_data` | خام بائٹس کے طور پر صوابدیدی اضافی ڈیٹا |
| `base_fee_per_gas` | بنیادی فیس کی ویلیو |
| `block_hash` | ایگزیکیوشن بلاک کا ہیش |
| `transactions` | ایگزیکیوٹ کی جانے والی ٹرانزیکشنز کی فہرست |
| `withdrawals` | انخلا کے آبجیکٹس کی فہرست |

`withdrawals` فہرست میں `withdrawal` آبجیکٹس شامل ہیں جو درج ذیل طریقے سے بنائے گئے ہیں:

| فیلڈ | تفصیل |
| :--------------- | :--------------------------------- |
| `address` | اکاؤنٹ کا پتہ جس نے انخلا کیا ہے |
| `amount` | انخلا کی رقم |
| `index` | انخلا کے اشاریے کی ویلیو |
| `validatorIndex` | توثیق کار کے اشاریے کی ویلیو |

## بلاک کا وقت {#block-time}

بلاک کا وقت بلاکس کو الگ کرنے والے وقت کو کہتے ہیں۔ ایتھیریم میں، وقت کو بارہ سیکنڈ کی اکائیوں میں تقسیم کیا گیا ہے جنہیں 'سلاٹس' کہا جاتا ہے۔ ہر سلاٹ میں ایک بلاک تجویز کرنے کے لیے ایک ہی توثیق کار کا انتخاب کیا جاتا ہے۔ یہ فرض کرتے ہوئے کہ تمام توثیق کار آن لائن ہیں اور مکمل طور پر فعال ہیں، ہر سلاٹ میں ایک بلاک ہوگا، جس کا مطلب ہے کہ بلاک کا وقت <span dir="ltr">12s</span> ہے۔ تاہم، کبھی کبھار توثیق کار آف لائن ہو سکتے ہیں جب انہیں بلاک تجویز کرنے کے لیے بلایا جاتا ہے، جس کا مطلب ہے کہ سلاٹس بعض اوقات خالی رہ سکتے ہیں۔

یہ عمل درآمد ثبوتِ کار (PoW) پر مبنی سسٹمز سے مختلف ہے جہاں بلاک کے اوقات امکانی ہوتے ہیں اور پروٹوکول کی ہدف شدہ کان کنی کی دشواری کے ذریعے ترتیب دیے جاتے ہیں۔ ایتھیریم کا [اوسط بلاک کا وقت](https://etherscan.io/chart/blocktime) اس کی ایک بہترین مثال ہے جس کے تحت ثبوتِ کار (PoW) سے حصہ داری کا ثبوت (PoS) میں منتقلی کا واضح طور پر نئے <span dir="ltr">12s</span> بلاک کے وقت کی مستقل مزاجی کی بنیاد پر اندازہ لگایا جا سکتا ہے۔

## بلاک کا سائز {#block-size}

ایک آخری اہم بات یہ ہے کہ بلاکس خود سائز میں محدود ہوتے ہیں۔ ہر بلاک کا ہدف سائز <span dir="ltr">30 million gas</span> ہوتا ہے لیکن بلاکس کا سائز نیٹ ورک کے مطالبات کے مطابق بڑھے گا یا کم ہوگا، جو کہ <span dir="ltr">60 million gas</span> کی بلاک کی حد تک جا سکتا ہے (ہدف بلاک کے سائز کا <span dir="ltr">2x</span>)۔ بلاک کی گیس کی حد کو پچھلے بلاک کی گیس کی حد سے <span dir="ltr">1/1024</span> کے فیکٹر سے اوپر یا نیچے ایڈجسٹ کیا جا سکتا ہے۔ نتیجے کے طور پر، توثیق کار اتفاق رائے کے ذریعے بلاک کی گیس کی حد کو تبدیل کر سکتے ہیں۔ بلاک میں تمام ٹرانزیکشنز کے ذریعے خرچ کی جانے والی گیس کی کل مقدار بلاک کی گیس کی حد سے کم ہونی چاہیے۔ یہ اہم ہے کیونکہ یہ یقینی بناتا ہے کہ بلاکس من مانی طور پر بڑے نہیں ہو سکتے۔ اگر بلاکس من مانی طور پر بڑے ہو سکتے ہیں، تو کم کارکردگی والے فل نوڈز جگہ اور رفتار کی ضروریات کی وجہ سے بتدریج نیٹ ورک کے ساتھ چلنے کے قابل نہیں رہیں گے۔ بلاک جتنا بڑا ہوگا، اگلے سلاٹ کے لیے وقت پر ان پر کارروائی کرنے کے لیے اتنی ہی زیادہ کمپیوٹنگ پاور درکار ہوگی۔ یہ ایک مرکزیت پیدا کرنے والی قوت ہے، جس کی مزاحمت بلاک کے سائز کو محدود کر کے کی جاتی ہے۔

## مزید مطالعہ {#further-reading}

_کسی ایسے کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحے میں ترمیم کریں اور اسے شامل کریں!_

## متعلقہ موضوعات {#related-topics}

- [ٹرانزیکشنز](/developers/docs/transactions/)
- [گیس](/developers/docs/gas/)
- [حصہ داری کا ثبوت (PoS)](/developers/docs/consensus-mechanisms/pos)

<QuizWidget quizKey="blocks" />