--- title: "فوساکا 🦓" metaTitle: "فولو-اوساکا (فوساکا)" description: "فوساکا پروٹوکول اپ گریڈ کے بارے میں جانیں" lang: ur template: upgrade authors: ["نکسو", "ماریو ہیول"] --- **ایتھیریم کا انتہائی متوقع فوساکا اپ گریڈ December 3, 2025 کو لائیو ہو گیا** فوساکا نیٹ ورک اپ گریڈ [پیکٹرا](/roadmap/pectra/) کے بعد آتا ہے اور مزید نئی خصوصیات لاتا ہے اور ہر [ایتھیریم](/) صارف اور ڈویلپر کے لیے تجربے کو بہتر بناتا ہے۔ یہ نام عمل درآمد کی تہہ کے اپ گریڈ اوساکا اور فولو ستارے کے نام پر رکھی گئی اتفاق رائے کی تہہ کے ورژن پر مشتمل ہے۔ ایتھیریم کے دونوں حصوں کو ایک اپ گریڈ ملتا ہے جو ایتھیریم کی اسکیلنگ، سیکیورٹی اور صارف کے تجربے کو مستقبل کی طرف دھکیلتا ہے۔ فوساکا اپ گریڈ ایتھیریم کے طویل مدتی ترقیاتی اہداف میں صرف ایک قدم ہے۔ [پروٹوکول روڈ میپ](/roadmap/) اور [پچھلے اپ گریڈز](/ethereum-forks/) کے بارے میں مزید جانیں۔ ## فوساکا میں بہتری {#improvements-in-fusaka} ### بلابز کو اسکیل کریں {#scale-blobs} #### PeerDAS {#peerdas} یہ فوساکا فورک کی _اہم خصوصیت_ ہے، جو اس اپ گریڈ میں شامل کی گئی ہے۔ لیئر ۲ (L2s) فی الحال اپنا ڈیٹا ایتھیریم پر بلابز میں پوسٹ کرتے ہیں، جو خاص طور پر لیئر ۲ کے لیے بنائی گئی عارضی ڈیٹا کی قسم ہے۔ فوساکا سے پہلے، ہر مکمل نوڈ کو ہر بلاب کو اسٹور کرنا پڑتا تھا تاکہ یہ یقینی بنایا جا سکے کہ ڈیٹا موجود ہے۔ جیسے جیسے بلاب کا تھرو پٹ بڑھتا ہے، اس تمام ڈیٹا کو ڈاؤن لوڈ کرنا وسائل کے لحاظ سے ناقابل برداشت حد تک مشکل ہو جاتا ہے۔ [ڈیٹا کی دستیابی کی سیمپلنگ](https://notes.ethereum.org/@fradamt/das-fork-choice) کے ساتھ، تمام بلاب ڈیٹا کو اسٹور کرنے کے بجائے، ہر نوڈ بلاب ڈیٹا کے ایک ذیلی سیٹ کا ذمہ دار ہوگا۔ بلابز کو نیٹ ورک میں نوڈز کے درمیان یکساں طور پر تصادفی طور پر تقسیم کیا جاتا ہے جس میں ہر مکمل نوڈ ڈیٹا کا صرف 1/8th حصہ رکھتا ہے، اس طرح نظریاتی طور پر 8x تک اسکیلنگ ممکن ہوتی ہے۔ ڈیٹا کی دستیابی کو یقینی بنانے کے لیے، ڈیٹا کے کسی بھی حصے کو پورے کے کسی بھی موجودہ 50% سے ایسے طریقوں سے دوبارہ بنایا جا سکتا ہے جو غلط یا غائب ڈیٹا کے امکان کو کرپٹوگرافک طور پر نہ ہونے کے برابر سطح تک کم کر دیتے ہیں (تقریباً 1020 میں ایک سے 1024 میں ایک تک)۔ یہ نوڈز کے لیے ہارڈویئر اور بینڈوتھ کی ضروریات کو قابل برداشت رکھتا ہے جبکہ بلاب اسکیلنگ کو فعال کرتا ہے جس کے نتیجے میں لیئر ۲ کے لیے کم فیس کے ساتھ زیادہ اسکیلنگ ہوتی ہے۔ [PeerDAS کے بارے میں مزید جانیں](/roadmap/fusaka/peerdas/) **وسائل**: - [EIP-7594 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7594) - [PeerDAS پر DappLion: آج ایتھیریم کی اسکیلنگ | ETHSofia 2024](https://youtu.be/bONWd1x2TjQ?t=328) - [تعلیمی: ایتھیریم کے PeerDAS کی دستاویزات (PDF)](https://eprint.iacr.org/2024/1362.pdf) #### صرف بلاب پیرامیٹر والے فورکس {#blob-parameter-only-forks} لیئر ۲ ایتھیریم کو اسکیل کرتے ہیں - جیسے جیسے ان کے نیٹ ورکس بڑھتے ہیں، انہیں ایتھیریم پر مزید ڈیٹا پوسٹ کرنے کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ وقت گزرنے کے ساتھ ایتھیریم کو ان کے لیے دستیاب بلابز کی تعداد میں اضافہ کرنا ہوگا۔ اگرچہ PeerDAS بلاب ڈیٹا کو اسکیل کرنے کے قابل بناتا ہے، لیکن اسے بتدریج اور محفوظ طریقے سے کرنے کی ضرورت ہے۔ چونکہ ایتھیریم ہزاروں آزاد نوڈز پر چلنے والا کوڈ ہے جنہیں یکساں اصولوں پر اتفاق رائے کی ضرورت ہوتی ہے، اس لیے ہم ویب سائٹ اپ ڈیٹ تعینات کرنے کی طرح بلاب کی تعداد بڑھانے جیسی تبدیلیاں آسانی سے متعارف نہیں کروا سکتے۔ کسی بھی اصول کی تبدیلی کو ایک مربوط اپ گریڈ ہونا چاہیے جہاں ہر نوڈ، کلائنٹ اور توثیق کار سافٹ ویئر ایک ہی پہلے سے طے شدہ بلاک سے پہلے اپ گریڈ ہو۔ ان مربوط اپ گریڈز میں عام طور پر بہت سی تبدیلیاں شامل ہوتی ہیں، بہت زیادہ ٹیسٹنگ کی ضرورت ہوتی ہے، اور اس میں وقت لگتا ہے۔ لیئر ۲ کی بلاب کی بدلتی ہوئی ضروریات کو تیزی سے اپنانے کے لیے، صرف بلاب پیرامیٹر والے فورکس اس اپ گریڈ شیڈول کا انتظار کیے بغیر بلابز کو بڑھانے کا ایک طریقہ کار متعارف کراتے ہیں۔ صرف بلاب پیرامیٹر والے فورکس کلائنٹس کے ذریعے سیٹ کیے جا سکتے ہیں، بالکل اسی طرح جیسے گیس کی حد جیسی دیگر کنفیگریشنز۔ ایتھیریم کے بڑے اپ گریڈز کے درمیان، کلائنٹس `target` اور `max` بلابز کو بڑھا کر مثال کے طور پر 9 اور 12 کرنے پر متفق ہو سکتے ہیں اور پھر نوڈ آپریٹرز اس چھوٹے فورک میں حصہ لینے کے لیے اپ ڈیٹ کریں گے۔ یہ صرف بلاب پیرامیٹر والے فورکس کسی بھی وقت کنفیگر کیے جا سکتے ہیں۔ جب ڈینکون اپ گریڈ میں پہلی بار نیٹ ورک میں بلابز شامل کیے گئے تھے، تو ہدف 3 تھا۔ پیکٹرا میں اسے بڑھا کر 6 کر دیا گیا تھا اور، فوساکا کے بعد، اب اسے ان بڑے نیٹ ورک اپ گریڈز سے آزادانہ طور پر ایک پائیدار شرح پر بڑھایا جا سکتا ہے۔ ![Chart showing average blob count per block and increasing targets with upgrades](./average-blob-count-per-block.webp) گراف کا ماخذ: [ایتھیریم بلابز - @hildobby، Dune Analytics](https://dune.com/hildobby/blobs) **وسائل**: [EIP-7892 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7892) #### عمل درآمد کی لاگت سے منسلک بلاب کی بنیادی فیس {#blob-base-fee-bounded-by-execution-costs} لیئر ۲ جب ڈیٹا پوسٹ کرتے ہیں تو دو بل ادا کرتے ہیں: بلاب فیس اور ان بلابز کی تصدیق کے لیے درکار عمل درآمد کی گیس۔ اگر عمل درآمد کی گیس کا غلبہ ہو، تو بلاب فیس کی نیلامی گر کر 1 Wei تک آ سکتی ہے اور قیمت کا اشارہ بننا بند ہو سکتی ہے۔ EIP-7918 ہر بلاب کے تحت ایک متناسب ریزرو قیمت مقرر کرتا ہے۔ جب ریزرو معمولی بلاب کی بنیادی فیس سے زیادہ ہوتا ہے، تو فیس ایڈجسٹمنٹ الگورتھم بلاک کو ہدف سے زیادہ سمجھتا ہے اور فیس کو نیچے دھکیلنا بند کر دیتا ہے اور اسے عام طور پر بڑھنے دیتا ہے۔ اس کے نتیجے میں: - بلاب فیس مارکیٹ ہمیشہ ہجوم (congestion) پر ردعمل ظاہر کرتی ہے - لیئر ۲ کم از کم اس کمپیوٹ کا ایک بامعنی حصہ ادا کرتے ہیں جو وہ نوڈز پر مسلط کرتے ہیں - عمل درآمد کی تہہ (EL) پر بنیادی فیس میں اضافہ اب بلاب فیس کو 1 Wei پر نہیں روک سکتا **وسائل**: - [EIP-7918 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7918) - [اسٹوری بک کی وضاحت](https://notes.ethereum.org/@anderselowsson/AIG) ### لیئر ۱ (L1) کو اسکیل کریں {#scale-l1} #### ہسٹری ایکسپائری اور آسان رسیدیں {#history-expiry} July 2025 میں، ایتھیریم کے عمل درآمد کے کلائنٹس نے [جزوی ہسٹری ایکسپائری کو سپورٹ کرنا شروع کر دیا](https://blog.ethereum.org/2025/07/08/partial-history-exp)۔ اس نے [دی مرج](https://ethereum.org/roadmap/merge/) سے پرانی ہسٹری کو ہٹا دیا تاکہ نوڈ آپریٹرز کے لیے درکار ڈسک اسپیس کو کم کیا جا سکے کیونکہ ایتھیریم مسلسل بڑھ رہا ہے۔ یہ EIP "بنیادی EIPs" سے الگ ایک سیکشن میں ہے کیونکہ فورک دراصل کوئی تبدیلی نافذ نہیں کرتا - یہ ایک نوٹس ہے کہ کلائنٹ ٹیموں کو فوساکا اپ گریڈ تک ہسٹری ایکسپائری کو سپورٹ کرنا چاہیے۔ عملی طور پر، کلائنٹس اسے کسی بھی وقت نافذ کر سکتے ہیں لیکن اسے اپ گریڈ میں شامل کرنے سے یہ ٹھوس طور پر ان کی ٹو ڈو لسٹ میں آ گیا اور انہیں اس خصوصیت کے ساتھ مل کر فوساکا کی تبدیلیوں کو جانچنے کے قابل بنایا۔ **وسائل**: [EIP-7642 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7642) #### MODEXP کے لیے اوپری حدیں مقرر کریں {#set-upper-bounds-for-modexp} اب تک، MODEXP پری کمپائل عملی طور پر کسی بھی سائز کے نمبرز کو قبول کرتا تھا۔ اس نے اسے ٹیسٹ کرنا مشکل، غلط استعمال کرنا آسان، اور کلائنٹ کے استحکام کے لیے خطرناک بنا دیا۔ EIP-7823 ایک واضح حد مقرر کرتا ہے: ہر ان پٹ نمبر زیادہ سے زیادہ 8192 bits (1024 bytes) طویل ہو سکتا ہے۔ اس سے بڑی کسی بھی چیز کو مسترد کر دیا جاتا ہے، ٹرانزیکشن کی گیس جل جاتی ہے، اور حالت میں کوئی تبدیلی نہیں ہوتی ہے۔ یہ انتہائی صورتوں کو ہٹاتے ہوئے حقیقی دنیا کی ضروریات کو بہت آسانی سے پورا کرتا ہے جنہوں نے گیس کی حد کی منصوبہ بندی اور سیکیورٹی جائزوں کو پیچیدہ بنا دیا تھا۔ یہ تبدیلی صارف یا ڈویلپر کے تجربے کو متاثر کیے بغیر مزید سیکیورٹی اور DoS تحفظ فراہم کرتی ہے۔ **وسائل**: [EIP-7823 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7823) #### ٹرانزیکشن گیس کی حد کی کیپ {#transaction-gas-limit-cap} EIP-[7825](https://eips.ethereum.org/EIPS/eip-7825) فی ٹرانزیکشن 16,777,216 (2^24) گیس کی کیپ کا اضافہ کرتا ہے۔ یہ بلاک گیس کی حد کو بڑھاتے وقت کسی بھی ایک ٹرانزیکشن کی بدترین صورتحال کی لاگت کو محدود کر کے فعال DoS ہارڈننگ ہے۔ یہ توثیق اور پھیلاؤ کو ماڈل کرنا آسان بناتا ہے تاکہ ہمیں گیس کی حد بڑھا کر اسکیلنگ سے نمٹنے کی اجازت مل سکے۔ بالکل 2^24 گیس ہی کیوں؟ یہ آج کی گیس کی حد سے کافی کم ہے، حقیقی کنٹریکٹ کی تعیناتیوں اور بھاری پری کمپائلز کے لیے کافی بڑی ہے، اور 2 کی طاقت اسے کلائنٹس میں نافذ کرنا آسان بناتی ہے۔ یہ نیا زیادہ سے زیادہ ٹرانزیکشن سائز پیکٹرا سے پہلے کے اوسط بلاک سائز کے مترادف ہے، جو اسے ایتھیریم پر کسی بھی آپریشن کے لیے ایک معقول حد بناتا ہے۔ **وسائل**: [EIP-7825 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7825) #### `MODEXP` گیس کی لاگت میں اضافہ {#modexp-gas-cost-increase} MODEXP ایک پری کمپائل بلٹ ان فنکشن ہے جو ماڈیولر ایکسپونینشیئشن کا حساب لگاتا ہے، جو RSA دستخط کی تصدیق اور پروف سسٹمز میں استعمال ہونے والی بڑے نمبروں کی ریاضی کی ایک قسم ہے۔ یہ کنٹریکٹس کو ان حسابات کو خود نافذ کیے بغیر براہ راست چلانے کی اجازت دیتا ہے۔ ڈویلپرز اور کلائنٹ ٹیموں نے MODEXP کو بلاک گیس کی حد بڑھانے میں ایک بڑی رکاوٹ کے طور پر شناخت کیا کیونکہ موجودہ گیس کی قیمتوں کا تعین اکثر اس بات کا کم اندازہ لگاتا ہے کہ کچھ ان پٹس کو کتنی کمپیوٹنگ پاور کی ضرورت ہے۔ اس کا مطلب ہے کہ MODEXP کا استعمال کرنے والی ایک ٹرانزیکشن پورے بلاک پر کارروائی کرنے کے لیے درکار زیادہ تر وقت لے سکتی ہے، جس سے نیٹ ورک سست ہو جاتا ہے۔ یہ EIP درج ذیل کے ذریعے حقیقی کمپیوٹیشنل اخراجات سے مطابقت رکھنے کے لیے قیمتوں کے تعین کو تبدیل کرتا ہے: - کم از کم چارج کو 200 سے بڑھا کر 500 گیس کرنا اور عام لاگت کے حساب کتاب پر EIP-2565 سے ایک تہائی رعایت کو ہٹانا - جب ایکسپونینٹ ان پٹ بہت طویل ہو تو لاگت میں زیادہ تیزی سے اضافہ کرنا۔ اگر ایکسپونینٹ (وہ "پاور" نمبر جو آپ دوسرے آرگومنٹ کے طور پر پاس کرتے ہیں) 32 bytes / 256 bits سے لمبا ہے، تو ہر اضافی بائٹ کے لیے گیس چارج بہت تیزی سے بڑھتا ہے - بڑے بیس یا ماڈیولس کے لیے بھی اضافی چارج کرنا۔ دیگر دو نمبرز (بیس اور ماڈیولس) کو کم از کم 32 bytes فرض کیا جاتا ہے - اگر کوئی ایک بڑا ہے، تو اس کے سائز کے تناسب سے لاگت بڑھ جاتی ہے لاگت کو اصل پروسیسنگ کے وقت سے بہتر طور پر ملا کر، MODEXP اب کسی بلاک کی توثیق میں بہت زیادہ وقت لگنے کا سبب نہیں بن سکتا۔ یہ تبدیلی ان کئی تبدیلیوں میں سے ایک ہے جن کا مقصد مستقبل میں ایتھیریم کی بلاک گیس کی حد کو بڑھانا محفوظ بنانا ہے۔ **وسائل**: [EIP-7883 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7883) #### RLP عمل درآمد کے بلاک سائز کی حد {#rlp-execution-block-size-limit} یہ اس بات پر ایک حد بناتا ہے کہ بلاک کو کتنا بڑا ہونے کی اجازت ہے - یہ اس بات کی حد ہے کہ نیٹ ورک پر کیا _بھیجا_ جاتا ہے اور یہ گیس کی حد سے الگ ہے، جو بلاک کے اندر _کام_ کو محدود کرتی ہے۔ بلاک سائز کی کیپ 10 MiB ہے، جس میں اتفاق رائے کے ڈیٹا کے لیے ایک چھوٹا الاؤنس (2 MiB) مخصوص ہے تاکہ ہر چیز فٹ ہو جائے اور صفائی سے پھیل سکے۔ اگر کوئی بلاک اس سے بڑا ظاہر ہوتا ہے، تو کلائنٹس اسے مسترد کر دیتے ہیں۔ اس کی ضرورت اس لیے ہے کیونکہ بہت بڑے بلاکس کو نیٹ ورک میں پھیلنے اور تصدیق کرنے میں زیادہ وقت لگتا ہے اور یہ اتفاق رائے کے مسائل پیدا کر سکتے ہیں یا DoS ویکٹر کے طور پر غلط استعمال ہو سکتے ہیں۔ اس کے علاوہ، اتفاق رائے کی تہہ کی گپ شپ (gossip) پہلے ہی ~10 MiB سے زیادہ کے بلاکس کو آگے نہیں بڑھائے گی، لہذا عمل درآمد کی تہہ کو اس حد کے ساتھ ہم آہنگ کرنے سے "کچھ نے دیکھا، دوسروں نے چھوڑ دیا" جیسی عجیب و غریب صورتحال سے بچا جا سکتا ہے۔ تفصیلات: یہ [RLP](/developers/docs/data-structures-and-encoding/rlp/)-انکوڈ شدہ عمل درآمد کے بلاک سائز پر ایک کیپ ہے۔ کل 10 MiB، جس میں بیکن بلاک فریمنگ کے لیے 2 MiB کا حفاظتی مارجن مخصوص ہے۔ عملی طور پر، کلائنٹس اس کی وضاحت کرتے ہیں `MAX_BLOCK_SIZE = 10,485,760` بائٹس اور `SAFETY_MARGIN = 2,097,152` بائٹس، اور کسی بھی ایسے عمل درآمد کے بلاک کو مسترد کر دیتے ہیں جس کا RLP پے لوڈ اس سے زیادہ ہو `MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE − SAFETY_MARGIN` اس کا مقصد بدترین صورتحال میں پھیلاؤ/توثیق کے وقت کو محدود کرنا اور اتفاق رائے کی تہہ کے گپ شپ کے رویے کے ساتھ ہم آہنگ کرنا ہے، جس سے گیس اکاؤنٹنگ کو تبدیل کیے بغیر تنظیمِ نو/DoS کے خطرے کو کم کیا جا سکے۔ **وسائل**: [EIP-7934 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7934) #### ڈیفالٹ گیس کی حد کو 60 ملین پر سیٹ کریں {#set-default-gas-limit-to-60-million} February 2025 میں گیس کی حد کو 30M سے بڑھا کر 36M (اور اس کے بعد 45M) کرنے سے پہلے، یہ قدر دی مرج (September 2022) کے بعد سے تبدیل نہیں ہوئی تھی۔ اس EIP کا مقصد مستقل اسکیلنگ کو ترجیح بنانا ہے۔ EIP-7935 فوساکا کے لیے ڈیفالٹ گیس کی حد کو آج کے 45M سے اوپر بڑھانے کے لیے EL کلائنٹ ٹیموں کو مربوط کرتا ہے۔ یہ ایک معلوماتی EIP ہے، لیکن یہ واضح طور پر کلائنٹس سے ڈیونیٹس پر اعلیٰ حدود کی جانچ کرنے، ایک محفوظ قدر پر متفق ہونے، اور اس نمبر کو اپنی فوساکا ریلیز میں شامل کرنے کا کہتا ہے۔ ڈیونیٹ کی منصوبہ بندی کا ہدف ~60M کا دباؤ (مصنوعی لوڈ کے ساتھ مکمل بلاکس) اور بتدریج اضافہ ہے؛ تحقیق کہتی ہے کہ بدترین صورتحال میں بلاک سائز کی خرابیاں ~150M سے نیچے نہیں ہونی چاہئیں۔ رول آؤٹ کو ٹرانزیکشن گیس کی حد کی کیپ (EIP-7825) کے ساتھ جوڑا جانا چاہیے تاکہ حدود بڑھنے پر کوئی ایک ٹرانزیکشن غلبہ حاصل نہ کر سکے۔ **وسائل**: [EIP-7935 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7935) ### UX کو بہتر بنائیں {#improve-ux} #### ڈیٹرمنسٹک تجویز کنندہ لک آہیڈ {#deterministic-proposer-lookahead} EIP-7917 کے ساتھ، بیکن چین اگلے دور کے لیے آنے والے بلاک تجویز کنندگان سے آگاہ ہو جائے گی۔ اس بات پر ایک ڈیٹرمنسٹک نظریہ رکھنا کہ کون سے توثیق کار مستقبل کے بلاکس تجویز کریں گے، [پری کنفرمیشنز](https://ethresear.ch/t/based-preconfirmations/17353) کو فعال کر سکتا ہے - آنے والے تجویز کنندہ کے ساتھ ایک کمٹمنٹ جو اس بات کی ضمانت دیتی ہے کہ صارف کی ٹرانزیکشن کو اصل بلاک کا انتظار کیے بغیر ان کے بلاک میں شامل کیا جائے گا۔ یہ خصوصیت کلائنٹ کے نفاذ اور نیٹ ورک کی سیکیورٹی کو فائدہ پہنچاتی ہے کیونکہ یہ ان انتہائی صورتوں کو روکتی ہے جہاں توثیق کار تجویز کنندہ کے شیڈول میں ہیرا پھیری کر سکتے ہیں۔ لک آہیڈ نفاذ کی کم پیچیدگی کی بھی اجازت دیتا ہے۔ **وسائل**: [EIP-7917 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7917) #### کاؤنٹ لیڈنگ زیروز (CLZ) آپ کوڈ {#count-leading-zeros-opcode} یہ خصوصیت ایک چھوٹی EVM ہدایت، **کاؤنٹ لیڈنگ زیروز (CLZ)** کا اضافہ کرتی ہے۔ EVM میں زیادہ تر ہر چیز کو 256-bit ویلیو کے طور پر پیش کیا جاتا ہے—یہ نیا آپ کوڈ واپس کرتا ہے کہ سامنے کتنے زیرو بٹس ہیں۔ یہ بہت سے انسٹرکشن سیٹ آرکیٹیکچرز میں ایک عام خصوصیت ہے کیونکہ یہ زیادہ موثر ریاضیاتی کارروائیوں کو قابل بناتا ہے۔ عملی طور پر یہ آج کے ہینڈ رولڈ بٹ اسکینز کو ایک قدم میں سمیٹ دیتا ہے، لہذا پہلا سیٹ بٹ تلاش کرنا، بائٹس کو اسکین کرنا، یا بٹ فیلڈز کو پارس کرنا آسان اور سستا ہو جاتا ہے۔ آپ کوڈ کم، مقررہ لاگت والا ہے اور اسے بنیادی اضافے کے برابر بینچ مارک کیا گیا ہے، جو بائٹ کوڈ کو تراشتا ہے اور اسی کام کے لیے گیس بچاتا ہے۔ **وسائل**: [EIP-7939 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7939) #### secp256r1 Curve سپورٹ کے لیے پری کمپائل {#secp256r1-precompile} مقررہ پتہ `0x100` پر ایک بلٹ ان، پاس کی طرز کا secp256r1 (P-256) دستخط چیکر متعارف کراتا ہے جو اسی کال فارمیٹ کا استعمال کرتا ہے جسے پہلے ہی بہت سے L2s نے اپنایا ہے اور انتہائی صورتوں کو ٹھیک کرتا ہے، تاکہ ان ماحول کے لیے لکھے گئے کنٹریکٹس بغیر کسی تبدیلی کے L1 پر کام کریں۔ UX اپ گریڈ! صارفین کے لیے، یہ ڈیوائس کے مقامی دستخط کرنے اور پاس کیز کو غیر مقفل کرتا ہے۔ والیٹس براہ راست Apple Secure Enclave، Android کی اسٹور، ہارڈویئر سیکیورٹی ماڈیولز (HSMs)، اور FIDO2/WebAuthn تک رسائی حاصل کر سکتے ہیں - کوئی سیڈ فریز نہیں، ہموار شمولیت، اور ملٹی فیکٹر فلو جو جدید ایپس کی طرح محسوس ہوتے ہیں۔ اس کے نتیجے میں بہتر UX، آسان ریکوری، اور اکاؤنٹ کی تجرید کے پیٹرن ملتے ہیں جو اس سے ملتے جلتے ہیں جو اربوں ڈیوائسز پہلے ہی کرتی ہیں۔ ڈویلپرز کے لیے، یہ 160-byte ان پٹ لیتا ہے اور 32-byte آؤٹ پٹ واپس کرتا ہے، جس سے موجودہ لائبریریوں اور L2 کنٹریکٹس کو پورٹ کرنا آسان ہو جاتا ہے۔ اندرونی طور پر، اس میں پوائنٹ-ایٹ-انفینٹی اور ماڈیولر-موازنہ چیک شامل ہیں تاکہ درست کالرز کو توڑے بغیر مشکل انتہائی صورتوں کو ختم کیا جا سکے۔ **وسائل**: - [EIP-7951 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7951) - [RIP-7212 کے بارے میں مزید](https://www.alchemy.com/blog/what-is-rip-7212) _(نوٹ کریں کہ EIP-7951 نے RIP-7212 کی جگہ لے لی ہے)_ ### میٹا {#meta} #### `eth_config` جے سن آر پی سی طریقہ {#eth-config} یہ ایک جے سن آر پی سی کال ہے جو آپ کو اپنے نوڈ سے یہ پوچھنے کی اجازت دیتی ہے کہ آپ کون سی فورک سیٹنگز چلا رہے ہیں۔ یہ تین اسنیپ شاٹس واپس کرتا ہے: `current`، `next`، اور `last` تاکہ توثیق کار اور مانیٹرنگ ٹولز اس بات کی تصدیق کر سکیں کہ کلائنٹس آنے والے فورک کے لیے تیار ہیں۔ عملی طور پر، یہ اس خامی کو دور کرنے کے لیے ہے جو اس وقت دریافت ہوئی تھی جب پیکٹرا فورک 2025 کے اوائل میں ہولسکی آزمائشی نیٹ ورک پر معمولی غلط کنفیگریشنز کے ساتھ لائیو ہوا تھا جس کے نتیجے میں ایک غیر حتمی حالت پیدا ہوئی تھی۔ اس سے ٹیسٹنگ ٹیموں اور ڈویلپرز کو یہ یقینی بنانے میں مدد ملتی ہے کہ ڈیونیٹس سے آزمائشی نیٹ ورکس، اور آزمائشی نیٹ ورکس سے مین نیٹ کی طرف جاتے وقت بڑے فورکس توقع کے مطابق برتاؤ کریں گے۔ اسنیپ شاٹس میں شامل ہیں: `chainId`، `forkId`، منصوبہ بند فورک کی فعال سازی کا وقت، کون سے پری کمپائلز فعال ہیں، پری کمپائل پتے، سسٹم کنٹریکٹ کا انحصار، اور فورک کا بلاب شیڈول۔ یہ EIP "بنیادی EIPs" سے الگ ایک سیکشن میں ہے کیونکہ فورک دراصل کوئی تبدیلی نافذ نہیں کرتا - یہ ایک نوٹس ہے کہ کلائنٹ ٹیموں کو فوساکا اپ گریڈ تک اس جے سن آر پی سی طریقہ کو نافذ کرنا چاہیے۔ **وسائل**: [EIP-7910 تکنیکی تفصیلات](https://eips.ethereum.org/EIPS/eip-7910) ## اکثر پوچھے گئے سوالات {#faq} ### کیا یہ اپ گریڈ تمام ایتھیریم نوڈز اور توثیق کاروں کو متاثر کرتا ہے؟ {#does-this-upgrade-affect-all-ethereum-nodes-and-validators} جی ہاں، فوساکا اپ گریڈ کے لیے [عمل درآمد کے کلائنٹس اور اتفاق رائے کے کلائنٹس](/developers/docs/nodes-and-clients/) دونوں میں اپ ڈیٹس کی ضرورت ہے۔ تمام اہم ایتھیریم کلائنٹس ہارڈ فورک کو سپورٹ کرنے والے ورژنز جاری کریں گے جنہیں اعلیٰ ترجیح کے طور پر نشان زد کیا گیا ہے۔ آپ اس بات سے باخبر رہ سکتے ہیں کہ یہ ریلیزز کلائنٹ کی GitHub ریپوز، ان کے [ڈسکارڈ چینلز](https://ethstaker.org/support)، [EthStaker ڈسکارڈ](https://dsc.gg/ethstaker) میں کب دستیاب ہوں گی، یا پروٹوکول اپ ڈیٹس کے لیے ایتھیریم بلاگ کو سبسکرائب کر کے۔ اپ گریڈ کے بعد ایتھیریم نیٹ ورک کے ساتھ ہم آہنگی برقرار رکھنے کے لیے، نوڈ آپریٹرز کو یہ یقینی بنانا چاہیے کہ وہ ایک سپورٹڈ کلائنٹ ورژن چلا رہے ہیں۔ نوٹ کریں کہ کلائنٹ کی ریلیزز کے بارے میں معلومات وقت کے لحاظ سے حساس ہیں، اور صارفین کو تازہ ترین تفصیلات کے لیے تازہ ترین اپ ڈیٹس کا حوالہ دینا چاہیے۔ ### ہارڈ فورک کے بعد ETH کو کیسے تبدیل کیا جا سکتا ہے؟ {#how-can-eth-be-converted-after-the-hardfork} - **آپ کے ETH کے لیے کسی کارروائی کی ضرورت نہیں ہے**: ایتھیریم فوساکا اپ گریڈ کے بعد، آپ کے ETH کو تبدیل یا اپ گریڈ کرنے کی کوئی ضرورت نہیں ہے۔ آپ کے اکاؤنٹ کے بیلنس وہی رہیں گے، اور جو ETH آپ کے پاس فی الحال ہے وہ ہارڈ فورک کے بعد اپنی موجودہ شکل میں قابل رسائی رہے گا۔ - **اسکیمز سے ہوشیار رہیں!** **کوئی بھی جو آپ کو اپنے ETH کو "اپ گریڈ" کرنے کی ہدایت کر رہا ہے وہ آپ کو دھوکہ دینے کی کوشش کر رہا ہے۔** اس اپ گریڈ کے سلسلے میں آپ کو کچھ کرنے کی ضرورت نہیں ہے۔ آپ کے اثاثے مکمل طور پر غیر متاثر رہیں گے۔ یاد رکھیں، باخبر رہنا اسکیمز کے خلاف بہترین دفاع ہے۔ [اسکیمز کو پہچاننے اور ان سے بچنے کے بارے میں مزید](/security/) ### زیبروں کا کیا چکر ہے؟ {#whats-with-the-zebras} زیبرا فوساکا کا ڈویلپرز کا منتخب کردہ "شوبنکر (mascot)" ہے کیونکہ اس کی دھاریاں PeerDAS کی کالم پر مبنی ڈیٹا کی دستیابی کی سیمپلنگ کی عکاسی کرتی ہیں، جہاں نوڈز کچھ کالم سب نیٹس کی تحویل میں لیتے ہیں اور ہر ساتھی کے سلاٹ سے کچھ دوسرے کالمز کا نمونہ لیتے ہیں تاکہ یہ چیک کیا جا سکے کہ بلاب ڈیٹا دستیاب ہے۔ 2022 میں دی مرج نے عمل درآمد اور اتفاق رائے کی تہوں کے ملنے کا اشارہ دینے کے لیے [ایک پانڈا کا استعمال کیا](https://x.com/hwwonx/status/1431970802040127498) اپنے شوبنکر کے طور پر۔ اس کے بعد سے، ہر فورک کے لیے غیر رسمی طور پر شوبنکر منتخب کیے گئے ہیں اور اپ گریڈ کے وقت کلائنٹ لاگز میں ASCII آرٹ کے طور پر ظاہر ہوتے ہیں۔ یہ جشن منانے کا صرف ایک تفریحی طریقہ ہے۔ ### L2 اسکیلنگ کے لیے کون سی بہتری شامل ہے؟ {#what-improvements-are-included-for-l2-scaling} [PeerDAS](/roadmap/fusaka/peerdas) فورک کی اہم خصوصیت ہے۔ یہ ڈیٹا کی دستیابی کی سیمپلنگ (DAS) کو نافذ کرتا ہے جو رول اپس کے لیے مزید اسکیل ایبلٹی کو غیر مقفل کرتا ہے، نظریاتی طور پر بلاب اسپیس کو موجودہ سائز سے 8 times تک اسکیل کرتا ہے۔ بلاب فیس مارکیٹ کو بھی بہتر بنایا جائے گا تاکہ ہجوم پر مؤثر طریقے سے ردعمل ظاہر کیا جا سکے اور اس بات کی ضمانت دی جا سکے کہ L2s اس کمپیوٹ اور اسپیس کے لیے ایک بامعنی فیس ادا کریں جو بلابز نوڈز پر مسلط کرتے ہیں۔ ### BPO فورکس کیسے مختلف ہیں؟ {#how-are-bpo-forks-different} صرف بلاب پیرامیٹر (BPO) فورکس PeerDAS کے فعال ہونے کے بعد بلاب کی تعداد (ہدف اور زیادہ سے زیادہ دونوں) کو مسلسل بڑھانے کا ایک طریقہ کار فراہم کرتے ہیں، بغیر کسی مکمل مربوط اپ گریڈ کا انتظار کیے۔ ہر اضافے کو فوساکا کو سپورٹ کرنے والی کلائنٹ ریلیزز میں پہلے سے کنفیگر کرنے کے لیے ہارڈ کوڈ کیا گیا ہے۔ ایک صارف یا توثیق کار کے طور پر، آپ کو ہر BPO کے لیے اپنے کلائنٹس کو اپ ڈیٹ کرنے کی ضرورت نہیں ہے اور صرف فوساکا جیسے بڑے ہارڈ فورکس کی پیروی کو یقینی بنائیں۔ یہ پہلے جیسی ہی مشق ہے، اس کے لیے کسی خاص کارروائی کی ضرورت نہیں ہے۔ پھر بھی یہ تجویز کیا جاتا ہے کہ اپ گریڈز اور BPOs کے ارد گرد اپنے کلائنٹس کی نگرانی کریں اور انہیں بڑی ریلیزز کے درمیان بھی اپ ڈیٹ رکھیں کیونکہ ہارڈ فورک کے بعد اصلاحات یا آپٹیمائزیشنز آ سکتی ہیں۔ ### BPO کا شیڈول کیا ہے؟ {#what-is-the-bpo-schedule} BPO اپ ڈیٹس کا قطعی شیڈول فوساکا ریلیزز کے ساتھ طے کیا جائے گا۔ [پروٹوکول کے اعلانات](https://blog.ethereum.org/category/protocol) اور اپنے کلائنٹس کے ریلیز نوٹس کی پیروی کریں۔ اس کی ایک مثال کہ یہ کیسا لگ سکتا ہے: - فوساکا سے پہلے: ہدف 6، زیادہ سے زیادہ 9 - فوساکا کی فعال سازی پر: ہدف 6، زیادہ سے زیادہ 9 - BPO1، فوساکا کی فعال سازی کے چند ہفتوں بعد: ہدف 10، زیادہ سے زیادہ 15، دو تہائی کا اضافہ - BPO2، BPO1 کے چند ہفتوں بعد: ہدف 14، زیادہ سے زیادہ 21 ### کیا اس سے ایتھیریم (لیئر ۱) پر فیس کم ہو جائے گی {#will-this-lower-gas} یہ اپ گریڈ L1 پر گیس کی فیس کو کم نہیں کرتا، کم از کم براہ راست نہیں۔ بنیادی توجہ رول اپ ڈیٹا کے لیے زیادہ بلاب اسپیس پر ہے، اس لیے لیئر ۲ پر فیس کم ہو رہی ہے۔ اس کے L1 فیس مارکیٹ پر کچھ ضمنی اثرات ہو سکتے ہیں لیکن کسی اہم تبدیلی کی توقع نہیں ہے۔ ### ایک اسٹیکر کے طور پر، مجھے اپ گریڈ کے لیے کیا کرنے کی ضرورت ہے؟ {#as-a-staker-what-do-i-need-to-do-for-the-upgrade} ہر نیٹ ورک اپ گریڈ کی طرح، اپنے کلائنٹس کو فوساکا سپورٹ کے ساتھ نشان زدہ تازہ ترین ورژنز میں اپ ڈیٹ کرنا یقینی بنائیں۔ ریلیزز کے بارے میں باخبر رہنے کے لیے میلنگ لسٹ اور [EF بلاگ پر پروٹوکول کے اعلانات](https://blog.ethereum.org/category/protocol) میں اپ ڈیٹس کی پیروی کریں۔ مین نیٹ پر فوساکا کے فعال ہونے سے پہلے اپنے سیٹ اپ کی توثیق کرنے کے لیے، آپ آزمائشی نیٹ ورکس پر ایک توثیق کار چلا سکتے ہیں۔ فوساکا [آزمائشی نیٹ ورکس پر جلد فعال ہو جاتا ہے](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) جس سے آپ کو یہ یقینی بنانے کے لیے زیادہ گنجائش ملتی ہے کہ ہر چیز کام کر رہی ہے اور بگز کی اطلاع دے سکتے ہیں۔ آزمائشی نیٹ ورک کے فورکس کا اعلان بھی میلنگ لسٹ اور بلاگ میں کیا جاتا ہے۔ ### کیا "ڈیٹرمنسٹک تجویز کنندہ لک آہیڈ" (EIP-7917) توثیق کاروں کو متاثر کرتا ہے؟ {#does-7917-affect-validators} یہ تبدیلی آپ کے توثیق کار کلائنٹ کے کام کرنے کے طریقے کو تبدیل نہیں کرتی ہے، تاہم، یہ آپ کے توثیق کار کے فرائض کے مستقبل کے بارے میں مزید بصیرت فراہم کرے گی۔ نئی خصوصیات کے ساتھ ہم آہنگ رہنے کے لیے اپنے مانیٹرنگ ٹولنگ کو اپ ڈیٹ کرنا یقینی بنائیں۔ ### فوساکا نوڈز اور توثیق کاروں کے لیے بینڈوتھ کی ضروریات کو کیسے متاثر کرتا ہے؟ {#how-does-fusaka-affect-bandwidth-requirements-for-nodes-and-validators} PeerDAS اس بات میں ایک اہم تبدیلی لاتا ہے کہ نوڈز بلاب ڈیٹا کو کیسے منتقل کرتے ہیں۔ تمام ڈیٹا کو 128 subnets میں کالمز کہلانے والے ٹکڑوں میں تقسیم کیا جاتا ہے جس میں نوڈز ان میں سے صرف کچھ کو سبسکرائب کرتے ہیں۔ سب نیٹ کالمز کی وہ مقدار جو نوڈز کو تحویل میں لینی ہوتی ہے ان کی کنفیگریشن اور منسلک توثیق کاروں کی تعداد پر منحصر ہے۔ اصل بینڈوتھ کی ضروریات نیٹ ورک میں اجازت یافتہ بلابز کی مقدار اور نوڈ کی قسم پر منحصر ہوں گی۔ فوساکا کی فعال سازی کے وقت بلاب کا ہدف پہلے جیسا ہی رہتا ہے، لیکن PeerDAS کے ساتھ، نوڈ آپریٹرز بلابز کے اپنے ڈسک کے استعمال اور نیٹ ورک ٹریفک میں کمی دیکھ سکتے ہیں۔ چونکہ BPOs نیٹ ورک میں بلابز کی زیادہ تعداد کو کنفیگر کرتے ہیں، اس لیے ہر BPO کے ساتھ ضروری بینڈوتھ میں اضافہ ہوگا۔ فوساکا BPOs کے بعد بھی نوڈز کی ضروریات [تجویز کردہ مارجنز](https://eips.ethereum.org/EIPS/eip-7870) کے اندر ہیں۔ #### مکمل نوڈز {#full-nodes} بغیر کسی توثیق کار کے باقاعدہ نوڈز صرف 4 سب نیٹس کو سبسکرائب کریں گے، جو اصل ڈیٹا کے 1/8 حصے کی تحویل فراہم کریں گے۔ اس کا مطلب ہے کہ بلاب ڈیٹا کی اتنی ہی مقدار کے ساتھ، انہیں ڈاؤن لوڈ کرنے کی نوڈ بینڈوتھ آٹھ (8) کے فیکٹر سے کم ہوگی۔ ایک عام مکمل نوڈ کے لیے بلابز کا ڈسک کا استعمال اور ڈاؤن لوڈ بینڈوتھ تقریباً 80% کم ہو کر صرف چند Mb رہ سکتی ہے۔ #### سولو اسٹیکرز {#solo-stakers} اگر نوڈ کو توثیق کار کلائنٹ کے لیے استعمال کیا جاتا ہے، تو اسے مزید کالمز کو تحویل میں لینا ہوگا اور اس لیے مزید ڈیٹا پر کارروائی کرنی ہوگی۔ ایک توثیق کار کے اضافے کے ساتھ، نوڈ کم از کم 8 کالم سب نیٹس کو سبسکرائب کرتا ہے اور اس لیے باقاعدہ نوڈ سے دوگنا ڈیٹا پر کارروائی کرتا ہے لیکن پھر بھی فوساکا سے کم۔ اگر توثیق کار کا بیلنس 287 ETH سے زیادہ ہے، تو زیادہ سے زیادہ سب نیٹس کو سبسکرائب کیا جائے گا۔ ایک سولو اسٹیکر کے لیے، اس کا مطلب ہے کہ ان کا ڈسک کا استعمال اور ڈاؤن لوڈ بینڈوتھ تقریباً 50% کم ہو جائے گی۔ تاہم مقامی طور پر بلاکس بنانے اور تمام بلابز کو نیٹ ورک پر اپ لوڈ کرنے کے لیے، زیادہ اپ لوڈ بینڈوتھ کی ضرورت ہوتی ہے۔ مقامی بلڈرز کو فوساکا کے وقت پہلے کی نسبت 2-3 times زیادہ اپ لوڈ بینڈوتھ کی ضرورت ہوگی اور 15/21 بلابز کے BPO2 ہدف کے ساتھ، حتمی ضروری اپ لوڈ بینڈوتھ تقریباً 5 times زیادہ، 100Mpbs پر ہونی چاہیے۔ #### بڑے توثیق کار {#large-validators} نوڈ میں مزید بیلنس اور توثیق کاروں کے اضافے کے ساتھ سبسکرائب شدہ سب نیٹس کی تعداد بڑھتی ہے۔ مثال کے طور پر، تقریباً 800 ETH بیلنس پر، نوڈ 25 کالمز کو تحویل میں لیتا ہے اور اسے پہلے کی نسبت تقریباً 30% زیادہ ڈاؤن لوڈ بینڈوتھ کی ضرورت ہوگی۔ ضروری اپ لوڈ باقاعدہ نوڈز کی طرح بڑھتا ہے اور کم از کم 100Mbps ضروری ہے۔ 4096 ETH پر، 2 زیادہ سے زیادہ بیلنس والے توثیق کاروں کے ساتھ، نوڈ 'سپر نوڈ' بن جاتا ہے جو تمام کالمز کو تحویل میں لیتا ہے، اس لیے ہر چیز کو ڈاؤن لوڈ اور اسٹور کرتا ہے۔ یہ نوڈز غائب ڈیٹا کو واپس دے کر نیٹ ورک کو فعال طور پر ٹھیک کرتے ہیں لیکن انہیں بہت زیادہ بینڈوتھ اور اسٹوریج کی بھی ضرورت ہوتی ہے۔ حتمی بلاب ہدف پہلے کی نسبت 6 times زیادہ ہونے کے ساتھ، سپر نوڈز کو تقریباً 600GB اضافی بلاب ڈیٹا اسٹور کرنا ہوگا اور ان کے پاس تقریباً 20Mbps پر تیز تر پائیدار ڈاؤن لوڈ بینڈوتھ ہونی چاہیے۔ [متوقع ضروریات کے بارے میں مزید تفصیلات پڑھیں۔](https://ethpandaops.io/posts/fusaka-bandwidth-estimation/#theoretical-requirements) ### کون سی EVM تبدیلیاں نافذ کی گئی ہیں؟ {#what-evm-changes-are-implemented} فوساکا نئی معمولی تبدیلیوں اور خصوصیات کے ساتھ EVM کو مستحکم کرتا ہے۔ - اسکیلنگ کے دوران سیکیورٹی کے لیے، ایک ٹرانزیکشن کا زیادہ سے زیادہ سائز گیس کی [16.7 million اکائیوں تک محدود](https://eips.ethereum.org/EIPS/eip-7825) ہوگا۔ - [نیا آپ کوڈ کاؤنٹ لیڈنگ زیروز (CLZ)](https://eips.ethereum.org/EIPS/eip-7939) EVM میں شامل کیا گیا ہے اور یہ سمارٹ کنٹریکٹ زبانوں کو کچھ کارروائیوں کو زیادہ مؤثر طریقے سے انجام دینے کے قابل بنائے گا۔ - [`ModExp` پری کمپائل کی لاگت میں اضافہ کیا جائے گا](https://eips.ethereum.org/EIPS/eip-7883)—اسے استعمال کرنے والے کنٹریکٹس عمل درآمد کے لیے زیادہ گیس چارج کریں گے۔ ### نئی 16M گیس کی حد کنٹریکٹ ڈویلپرز کو کیسے متاثر کرتی ہے؟ {#how-does-new-16m-gas-limit-affects-contract-developers} فوساکا [ایک ٹرانزیکشن کے زیادہ سے زیادہ سائز کو 16.7 million](https://eips.ethereum.org/EIPS/eip-7825) (2^24) گیس یونٹس تک محدود کرتا ہے۔ یہ تقریباً ایک اوسط بلاک کا پچھلا سائز ہے جو اسے اتنا بڑا بناتا ہے کہ وہ پیچیدہ ٹرانزیکشنز کو ایڈجسٹ کر سکے جو پورے بلاک کو استعمال کر لیں۔ یہ حد کلائنٹس کے لیے تحفظ پیدا کرتی ہے، جو مستقبل میں اعلیٰ بلاک گیس کی حد کے ساتھ ممکنہ DoS حملوں کو روکتی ہے۔ اسکیلنگ کا مقصد یہ ہے کہ زیادہ ٹرانزیکشنز کو بلاک چین میں شامل ہونے کے قابل بنایا جائے بغیر کسی ایک کے پورے بلاک کو استعمال کیے۔ باقاعدہ صارف کی ٹرانزیکشنز اس حد تک پہنچنے سے بہت دور ہیں۔ کچھ انتہائی صورتیں جیسے بڑے اور پیچیدہ غیر مرکزی مالیات (DeFi) آپریشنز، بڑی سمارٹ کنٹریکٹ کی تعیناتیاں یا متعدد کنٹریکٹس کو نشانہ بنانے والی بیچ ٹرانزیکشنز اس تبدیلی سے متاثر ہو سکتی ہیں۔ ان ٹرانزیکشنز کو چھوٹی ٹرانزیکشنز میں تقسیم کرنا ہوگا یا کسی اور طریقے سے آپٹیمائز کرنا ہوگا۔ ممکنہ طور پر حد تک پہنچنے والی ٹرانزیکشنز جمع کرانے سے پہلے سیمولیشن کا استعمال کریں۔ RPC طریقہ `eth_call` محدود نہیں ہے اور یہ اصل بلاک چین کی حد سے بڑی ٹرانزیکشنز کی سیمولیشن کی اجازت دے گا۔ غلط استعمال کو روکنے کو یقینی بنانے کے لیے کلائنٹ آپریٹر کے ذریعے RPC طریقوں کی اصل حد کو کنفیگر کیا جا سکتا ہے۔ ### ڈویلپرز کے لیے CLZ کا کیا مطلب ہے؟ {#what-clz-means-for-developers} Solidity جیسے EVM کمپائلرز اندرونی طور پر زیروز گننے کے لیے نئے فنکشن کو نافذ اور استعمال کریں گے۔ نئے کنٹریکٹس گیس کی بچت سے فائدہ اٹھا سکتے ہیں اگر وہ اس قسم کے آپریشن پر انحصار کرتے ہیں۔ ممکنہ بچت پر دستاویزات کے لیے سمارٹ کنٹریکٹ زبان کی ریلیزز اور خصوصیت کے اعلان کی پیروی کریں۔ ### کیا میرے موجودہ سمارٹ کنٹریکٹس کے لیے کوئی تبدیلیاں ہیں؟ {#what-clz-means-for-developers-2} فوساکا کا کوئی براہ راست اثر نہیں ہے جو کسی موجودہ کنٹریکٹس کو توڑ دے یا ان کے رویے کو تبدیل کرے۔ عمل درآمد کی تہہ میں متعارف کرائی گئی تبدیلیاں بیک ورڈ کمپیٹیبلٹی کے ساتھ کی گئی ہیں، تاہم، ہمیشہ انتہائی صورتوں اور ممکنہ اثرات پر نظر رکھیں۔ [`ModExp` پری کمپائل کی لاگت میں اضافے کے ساتھ](https://eips.ethereum.org/EIPS/eip-7883)، اس پر انحصار کرنے والے کنٹریکٹس عمل درآمد کے لیے زیادہ گیس استعمال کریں گے۔ اگر آپ کا کنٹریکٹ اس پر بہت زیادہ انحصار کرتا ہے اور صارفین کے لیے زیادہ مہنگا ہو جاتا ہے، تو اس بات پر دوبارہ غور کریں کہ اسے کیسے استعمال کیا جاتا ہے۔ اگر آپ کے کنٹریکٹس پر عمل درآمد کرنے والی ٹرانزیکشنز اسی طرح کے سائز تک پہنچ رہی ہیں تو [نئی 16.7 million کی حد](https://eips.ethereum.org/EIPS/eip-7825) پر غور کریں۔ ## مزید مطالعہ {#further-reading} - [ایتھیریم روڈ میپ](/roadmap/) - [فورک کاسٹ: فوساکا](https://forkcast.org/upgrade/fusaka) - [فوساکا میٹا EIP](https://eips.ethereum.org/EIPS/eip-7607) - [فوساکا آزمائشی نیٹ ورک بلاگ کا اعلان](https://blog.ethereum.org/2025/09/26/fusaka-testnet-announcement) - [Bankless: فوساکا اور پیکٹرا ایتھیریم کے لیے کیا لائیں گے](https://www.bankless.com/read/what-fusaka-pectra-will-bring-ethereum) - [Bankless: ایتھیریم کے اگلے اپ گریڈز: فوساکا، گلیمسٹرڈیم اور اس سے آگے Preston Van Loon کے ساتھ](https://x.com/BanklessHQ/status/1956017743289020633?t=502) - [دی فوساکا فائلز](https://www.youtube.com/playlist?list=PL4cwHXAawZxpz-erUbKKUnnGoQNdF8s7Z) - [PEEPanEIPs کی وضاحت](https://www.youtube.com/playlist?list=PL4cwHXAawZxoIenfk7OJry4rxcqX-eqBt)