بلاکس
صفحہ کی آخری اپ ڈیٹ: 23 فروری، 2026
بلاکس ٹرانزیکشنز کے بیچز (batches) ہوتے ہیں جن میں چین کے پچھلے بلاک کا ہیش (hash) شامل ہوتا ہے۔ یہ بلاکس کو ایک ساتھ (ایک چین میں) جوڑتا ہے کیونکہ ہیشز کو کرپٹوگرافک طریقے سے بلاک کے ڈیٹا سے اخذ کیا جاتا ہے۔ اس سے فراڈ کی روک تھام ہوتی ہے، کیونکہ تاریخ کے کسی بھی بلاک میں ایک تبدیلی اس کے بعد آنے والے تمام بلاکس کو غیر مستند کر دے گی کیونکہ اس کے بعد کے تمام ہیشز تبدیل ہو جائیں گے اور بلاک چین چلانے والے ہر شخص کو اس کا علم ہو جائے گا۔
بنیادی شرائط
بلاکس ایک بہت ہی ابتدائی سطح کا موضوع ہے۔ لیکن اس صفحے کو بہتر طور پر سمجھنے میں آپ کی مدد کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے اکاؤنٹس، ٹرانزیکشنز، اور ہمارا ایتھریم کا تعارف پڑھیں۔
بلاکس کیوں؟
اس بات کو یقینی بنانے کے لیے کہ Ethereum نیٹ ورک پر تمام شرکاء ایک ہم آہنگ اسٹیٹ (state) برقرار رکھیں اور ٹرانزیکشنز کی درست تاریخ پر متفق ہوں، ہم ٹرانزیکشنز کو بلاکس میں بیچ (batch) کرتے ہیں۔ اس کا مطلب ہے کہ درجنوں (یا سینکڑوں) ٹرانزیکشنز ایک ہی وقت میں کمٹ (commit)، متفق اور ہم آہنگ کی جاتی ہیں۔
خاکہ Ethereum EVM illustrated (opens in a new tab) سے لیا گیا ہے
کمٹس (commits) کے درمیان وقفہ دے کر، ہم نیٹ ورک کے تمام شرکاء کو اتفاق رائے (consensus) تک پہنچنے کے لیے کافی وقت دیتے ہیں: اگرچہ ٹرانزیکشن کی درخواستیں فی سیکنڈ درجنوں بار ہوتی ہیں، لیکن ایتھریم پر بلاکس ہر بارہ سیکنڈ میں صرف ایک بار بنائے اور کمٹ کیے جاتے ہیں۔
بلاکس کیسے کام کرتے ہیں
ٹرانزیکشن کی تاریخ کو محفوظ رکھنے کے لیے، بلاکس کو سختی سے ترتیب دیا جاتا ہے (ہر نیا بنایا گیا بلاک اپنے پیرنٹ بلاک کا حوالہ رکھتا ہے)، اور بلاکس کے اندر ٹرانزیکشنز کو بھی سختی سے ترتیب دیا جاتا ہے۔ شاذ و نادر صورتوں کے علاوہ، کسی بھی وقت، نیٹ ورک پر تمام شرکاء بلاکس کی صحیح تعداد اور تاریخ پر متفق ہوتے ہیں، اور موجودہ لائیو ٹرانزیکشن کی درخواستوں کو اگلے بلاک میں بیچ کرنے کے لیے کام کر رہے ہوتے ہیں۔
ایک بار جب نیٹ ورک پر تصادفی طور پر منتخب کردہ ویلیڈیٹر (validator) کے ذریعے ایک بلاک تیار کر لیا جاتا ہے، تو اسے باقی نیٹ ورک تک پھیلا دیا جاتا ہے؛ تمام نوڈز اس بلاک کو اپنی بلاک چین کے آخر میں شامل کرتے ہیں، اور اگلا بلاک بنانے کے لیے ایک نیا ویلیڈیٹر منتخب کیا جاتا ہے۔ بلاک کو جمع کرنے کا درست عمل اور کمٹمنٹ/اتفاق رائے کا عمل فی الحال ایتھریم کے "پروف آف اسٹیک" (proof-of-stake) پروٹوکول کے ذریعے متعین کیا گیا ہے۔
پروف آف اسٹیک پروٹوکول
پروف آف اسٹیک کا مطلب درج ذیل ہے:
- ویلیڈیٹنگ نوڈز کو برے سلوک کے خلاف ضمانت کے طور پر ڈپازٹ کنٹریکٹ میں 32 ETH اسٹیک کرنے ہوتے ہیں۔ اس سے نیٹ ورک کی حفاظت میں مدد ملتی ہے کیونکہ ثابت شدہ بے ایمانی کی سرگرمی اس اسٹیک کے کچھ یا تمام حصے کے ضائع ہونے کا سبب بنتی ہے۔
- ہر سلاٹ میں (بارہ سیکنڈ کے وقفے سے) ایک ویلیڈیٹر کو تصادفی طور پر بلاک پروپوزر (block proposer) کے طور پر منتخب کیا جاتا ہے۔ وہ ٹرانزیکشنز کو ایک ساتھ بنڈل کرتے ہیں، انہیں ایگزیکیوٹ کرتے ہیں اور ایک نئی 'اسٹیٹ' کا تعین کرتے ہیں۔ وہ اس معلومات کو ایک بلاک میں لپیٹتے ہیں اور اسے دوسرے ویلیڈیٹرز تک پہنچاتے ہیں۔
- دوسرے ویلیڈیٹرز جو نئے بلاک کے بارے میں سنتے ہیں وہ ٹرانزیکشنز کو دوبارہ ایگزیکیوٹ کرتے ہیں تاکہ یہ یقینی بنایا جا سکے کہ وہ گلوبل اسٹیٹ میں مجوزہ تبدیلی سے متفق ہیں۔ یہ فرض کرتے ہوئے کہ بلاک درست ہے، وہ اسے اپنے ڈیٹا بیس میں شامل کر لیتے ہیں۔
- اگر کوئی ویلیڈیٹر ایک ہی سلاٹ کے لیے دو متصادم بلاکس کے بارے میں سنتا ہے تو وہ اپنے فورک-چوائس (fork-choice) الگورتھم کا استعمال کرتے ہوئے اس بلاک کا انتخاب کرتا ہے جسے سب سے زیادہ اسٹیک کیے گئے ETH کی حمایت حاصل ہو۔
پروف آف اسٹیک کے بارے میں مزید
بلاک میں کیا ہوتا ہے؟
ایک بلاک کے اندر بہت سی معلومات موجود ہوتی ہیں۔ اعلیٰ ترین سطح پر ایک بلاک میں درج ذیل فیلڈز شامل ہوتی ہیں:
| فیلڈ | تفصیل |
|---|---|
slot | وہ سلاٹ جس سے بلاک تعلق رکھتا ہے |
proposer_index | بلاک تجویز کرنے والے ویلیڈیٹر کی ID |
parent_root | پچھلے بلاک کا ہیش |
state_root | اسٹیٹ آبجیکٹ کا روٹ ہیش |
body | ایک آبجیکٹ جس میں کئی فیلڈز شامل ہیں، جیسا کہ ذیل میں بیان کیا گیا ہے |
بلاک کی body میں اس کی اپنی کئی فیلڈز شامل ہوتی ہیں:
| فیلڈ | تفصیل |
|---|---|
randao_reveal | اگلا بلاک پروپوزر منتخب کرنے کے لیے استعمال ہونے والی ویلیو |
eth1_data | ڈپازٹ کنٹریکٹ کے بارے میں معلومات |
graffiti | بلاکس کو ٹیگ کرنے کے لیے استعمال ہونے والا صوابدیدی ڈیٹا |
proposer_slashings | سلیش (slash) کیے جانے والے ویلیڈیٹرز کی فہرست |
attester_slashings | سلیش کیے جانے والے اٹیسٹرز (attesters) کی فہرست |
attestations | پچھلے سلاٹس کے خلاف کی گئی تصدیقات (attestations) کی فہرست |
deposits | ڈپازٹ کنٹریکٹ میں نئے ڈپازٹس کی فہرست |
voluntary_exits | نیٹ ورک سے باہر نکلنے والے ویلیڈیٹرز کی فہرست |
sync_aggregate | لائٹ کلائنٹس کو سرو کرنے کے لیے استعمال ہونے والے ویلیڈیٹرز کا سب سیٹ |
execution_payload | ایگزیکیوشن کلائنٹ سے پاس کی گئی ٹرانزیکشنز |
attestations فیلڈ میں بلاک میں موجود تمام تصدیقات کی فہرست ہوتی ہے۔ تصدیقات کی اپنی ڈیٹا ٹائپ ہوتی ہے جس میں ڈیٹا کے کئی حصے شامل ہوتے ہیں۔ ہر تصدیق میں شامل ہوتا ہے:
| فیلڈ | تفصیل |
|---|---|
aggregation_bits | اس تصدیق میں کن ویلیڈیٹرز نے حصہ لیا، ان کی فہرست |
data | ایک کنٹینر جس میں متعدد ذیلی فیلڈز ہیں |
signature | data حصے کے خلاف ویلیڈیٹرز کے ایک سیٹ کے مجموعی دستخط |
attestation میں data فیلڈ میں درج ذیل شامل ہوتا ہے:
| فیلڈ | تفصیل |
|---|---|
slot | وہ سلاٹ جس سے تصدیق کا تعلق ہے |
index | تصدیق کرنے والے ویلیڈیٹرز کے انڈیکسز |
beacon_block_root | بیکن (Beacon) بلاک کا روٹ ہیش جسے چین کے ہیڈ (head) کے طور پر دیکھا جاتا ہے |
source | آخری جسٹیفائیڈ (justified) چیک پوائنٹ |
target | تازہ ترین ایپوک (epoch) باؤنڈری بلاک |
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 | خام بائٹس (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 | ویلیڈیٹر کی انڈیکس ویلیو |
بلاک کا وقت
بلاک ٹائم سے مراد وہ وقت ہے جو بلاکس کو الگ کرتا ہے۔ ایتھریم میں، وقت کو بارہ سیکنڈ کی اکائیوں میں تقسیم کیا گیا ہے جنہیں 'سلاٹس' (slots) کہا جاتا ہے۔ ہر سلاٹ میں ایک بلاک تجویز کرنے کے لیے ایک ہی ویلیڈیٹر کا انتخاب کیا جاتا ہے۔ یہ فرض کرتے ہوئے کہ تمام ویلیڈیٹرز آن لائن ہیں اور مکمل طور پر فعال ہیں، ہر سلاٹ میں ایک بلاک ہوگا، جس کا مطلب ہے کہ بلاک کا وقت 12 سیکنڈ ہے۔ تاہم، کبھی کبھار ویلیڈیٹرز آف لائن ہو سکتے ہیں جب انہیں بلاک تجویز کرنے کے لیے بلایا جاتا ہے، جس کا مطلب ہے کہ سلاٹس بعض اوقات خالی جا سکتے ہیں۔
یہ عمل درآمد پروف آف ورک (proof-of-work) پر مبنی سسٹمز سے مختلف ہے جہاں بلاک کے اوقات امکانی (probabilistic) ہوتے ہیں اور پروٹوکول کی ہدف شدہ مائننگ کی دشواری کے ذریعے ترتیب دیے جاتے ہیں۔ ایتھریم کا اوسط بلاک ٹائم (opens in a new tab) اس کی ایک بہترین مثال ہے جس کے ذریعے پروف آف ورک سے پروف آف اسٹیک میں منتقلی کا واضح طور پر نئے 12 سیکنڈ کے بلاک ٹائم کی مستقل مزاجی کی بنیاد پر اندازہ لگایا جا سکتا ہے۔
بلاک کا سائز
ایک آخری اہم بات یہ ہے کہ بلاکس بذات خود سائز میں محدود ہوتے ہیں۔ ہر بلاک کا ہدف سائز 30 ملین گیس ہوتا ہے لیکن بلاکس کا سائز نیٹ ورک کے مطالبات کے مطابق بڑھے گا یا کم ہوگا، جو کہ 60 ملین گیس (ہدف بلاک سائز کا 2 گنا) کی بلاک حد تک جا سکتا ہے۔ بلاک گیس کی حد کو پچھلے بلاک کی گیس کی حد سے 1/1024 کے فیکٹر سے اوپر یا نیچے ایڈجسٹ کیا جا سکتا ہے۔ نتیجے کے طور پر، ویلیڈیٹرز اتفاق رائے کے ذریعے بلاک گیس کی حد کو تبدیل کر سکتے ہیں۔ بلاک میں تمام ٹرانزیکشنز کے ذریعے خرچ کی جانے والی گیس کی کل مقدار بلاک گیس کی حد سے کم ہونی چاہیے۔ یہ اہم ہے کیونکہ یہ یقینی بناتا ہے کہ بلاکس من مانی طور پر بڑے نہیں ہو سکتے۔ اگر بلاکس من مانی طور پر بڑے ہو سکتے ہیں، تو کم کارکردگی والے فل نوڈز (full nodes) جگہ اور رفتار کی ضروریات کی وجہ سے بتدریج نیٹ ورک کے ساتھ چلنے کے قابل نہیں رہیں گے۔ بلاک جتنا بڑا ہوگا، اگلے سلاٹ کے لیے وقت پر ان پر کارروائی کرنے کے لیے اتنی ہی زیادہ کمپیوٹنگ پاور درکار ہوگی۔ یہ ایک سینٹرلائزنگ (centralizing) قوت ہے، جس کی مزاحمت بلاک کے سائز کو محدود کر کے کی جاتی ہے۔
مزید مطالعہ
کسی ایسے کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحے میں ترمیم کریں اور اسے شامل کریں!