مرکزی مواد پر جائیں
Change page

بلاکس

صفحہ کی آخری اپ ڈیٹ: 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ایک کنٹینر جس میں متعدد ذیلی فیلڈز ہیں
signaturedata حصے کے خلاف ویلیڈیٹرز کے ایک سیٹ کے مجموعی دستخط

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) قوت ہے، جس کی مزاحمت بلاک کے سائز کو محدود کر کے کی جاتی ہے۔

مزید مطالعہ

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

کیا یہ مضمون مددگار تھا؟