Fusaka

ایتھیریم کا انتہائی متوقع Fusaka اپ گریڈ 3 دسمبر 2025 کو لائیو ہو گیا

Fusaka نیٹ ورک اپ گریڈ Pectra کے بعد آتا ہے اور ہر Ethereum صارف اور ڈیولپر کے لیے مزید نئی خصوصیات لاتا ہے اور تجربے کو بہتر بناتا ہے۔ یہ نام ایگزیکیوشن لیئر اپ گریڈ Osaka اور کنسینسس لیئر ورژن پر مشتمل ہے جس کا نام Fulu ستارے کے نام پر رکھا گیا ہے۔ ایتھیریم کے دونوں حصوں کو ایک اپ گریڈ ملتا ہے جو ایتھیریم کی اسکیلنگ، سیکیورٹی اور صارف کے تجربے کو مستقبل کی طرف دھکیلتا ہے۔

Fusaka میں بہتری

اسکیل بلابز (Scale blobs)

PeerDAS

یہ Fusaka فورک کی ہیڈلائنر ہے، جو اس اپ گریڈ میں شامل کی گئی اہم خصوصیت ہے۔ لیئر 2s فی الحال اپنا ڈیٹا ایتھیریم پر بلابز (blobs) میں پوسٹ کرتے ہیں، جو خاص طور پر لیئر 2s کے لیے بنائی گئی عارضی ڈیٹا ٹائپ ہے۔ Fusaka سے پہلے، ہر فل نوڈ کو ہر بلاب کو اسٹور کرنا پڑتا تھا تاکہ یہ یقینی بنایا جا سکے کہ ڈیٹا موجود ہے۔ جیسے جیسے بلاب تھرو پٹ (throughput) بڑھتا ہے، اس تمام ڈیٹا کو ڈاؤن لوڈ کرنا وسائل کے لحاظ سے ناقابل برداشت حد تک مشکل ہو جاتا ہے۔

ڈیٹا کی دستیابی کی سیمپلنگ (data availability sampling) (opens in a new tab) کے ساتھ، تمام بلاب ڈیٹا کو اسٹور کرنے کے بجائے، ہر نوڈ بلاب ڈیٹا کے ایک سب سیٹ (subset) کا ذمہ دار ہوگا۔ بلابز کو نیٹ ورک میں نوڈز کے درمیان یکساں طور پر تصادفی (randomly) تقسیم کیا جاتا ہے جس میں ہر فل نوڈ ڈیٹا کا صرف 1/8 حصہ رکھتا ہے، اس طرح نظریاتی طور پر 8x تک اسکیلنگ ممکن ہو جاتی ہے۔ ڈیٹا کی دستیابی کو یقینی بنانے کے لیے، ڈیٹا کے کسی بھی حصے کو موجودہ 50% حصے سے دوبارہ تشکیل دیا جا سکتا ہے، ایسے طریقوں کے ساتھ جو غلط یا غائب ڈیٹا کے امکان کو کرپٹوگرافک طور پر نہ ہونے کے برابر سطح تک کم کر دیتے ہیں (~10²⁰ میں ایک سے 10²⁴ میں ایک تک)۔

یہ نوڈز کے لیے ہارڈویئر اور بینڈوتھ کی ضروریات کو قابل برداشت رکھتا ہے جبکہ بلاب اسکیلنگ کو فعال کرتا ہے جس کے نتیجے میں لیئر 2s کے لیے کم فیس کے ساتھ زیادہ اسکیلنگ ہوتی ہے۔

PeerDAS کے بارے میں مزید جانیں

وسائل:

• EIP-7594 تکنیکی تفصیلات (opens in a new tab)
• PeerDAS پر DappLion: آج ایتھیریم کی اسکیلنگ | ETHSofia 2024 (opens in a new tab)
• اکیڈمک: ایتھیریم کے PeerDAS کی دستاویزات (PDF) (opens in a new tab)

صرف بلاب پیرامیٹر (Blob-Parameter-Only) فورکس

لیئر 2s ایتھیریم کو اسکیل کرتے ہیں - جیسے جیسے ان کے نیٹ ورکس بڑھتے ہیں، انہیں ایتھیریم پر مزید ڈیٹا پوسٹ کرنے کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ وقت گزرنے کے ساتھ ایتھیریم کو ان کے لیے دستیاب بلابز کی تعداد میں اضافہ کرنا ہوگا۔ اگرچہ PeerDAS بلاب ڈیٹا کو اسکیل کرنے کے قابل بناتا ہے، لیکن اسے بتدریج اور محفوظ طریقے سے کرنے کی ضرورت ہے۔

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

ان مربوط اپ گریڈز میں عام طور پر بہت سی تبدیلیاں شامل ہوتی ہیں، بہت زیادہ ٹیسٹنگ کی ضرورت ہوتی ہے، اور اس میں وقت لگتا ہے۔ لیئر 2 کی بلاب کی بدلتی ہوئی ضروریات کو تیزی سے اپنانے کے لیے، صرف بلاب پیرامیٹر فورکس (blob parameter only forks) ایک ایسا طریقہ کار متعارف کراتے ہیں جس سے اس اپ گریڈ شیڈول کا انتظار کیے بغیر بلابز میں اضافہ کیا جا سکتا ہے۔

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

جب Dencun اپ گریڈ میں پہلی بار نیٹ ورک میں بلابز شامل کیے گئے تھے، تو ہدف 3 تھا۔ Pectra میں اسے بڑھا کر 6 کر دیا گیا تھا اور، Fusaka کے بعد، اب اسے ان بڑے نیٹ ورک اپ گریڈز سے آزادانہ طور پر ایک پائیدار شرح پر بڑھایا جا سکتا ہے۔

گراف کا ماخذ: Ethereum Blobs - @hildobby, Dune Analytics (opens in a new tab)

وسائل: EIP-7892 تکنیکی تفصیلات (opens in a new tab)

ایگزیکیوشن لاگت سے منسلک بلاب بیس فیس

لیئر 2s جب ڈیٹا پوسٹ کرتے ہیں تو دو بل ادا کرتے ہیں: بلاب فیس اور ان بلابز کی تصدیق کے لیے درکار ایگزیکیوشن گیس۔ اگر ایگزیکیوشن گیس کا غلبہ ہو، تو بلاب فیس کی نیلامی 1 wei تک گر سکتی ہے اور قیمت کا اشارہ بننا بند کر سکتی ہے۔

EIP-7918 ہر بلاب کے تحت ایک متناسب ریزرو قیمت (reserve price) مقرر کرتا ہے۔ جب ریزرو معمولی بلاب بیس فیس سے زیادہ ہوتا ہے، تو فیس ایڈجسٹمنٹ الگورتھم بلاک کو ہدف سے زیادہ (over target) سمجھتا ہے اور فیس کو نیچے دھکیلنا بند کر دیتا ہے اور اسے عام طور پر بڑھنے دیتا ہے۔ اس کے نتیجے میں:

• بلاب فیس مارکیٹ ہمیشہ ہجوم (congestion) پر ردعمل ظاہر کرتی ہے
• لیئر 2s کم از کم اس کمپیوٹ کا ایک بامعنی حصہ ادا کرتے ہیں جو وہ نوڈز پر مسلط کرتے ہیں
• EL پر بیس فیس میں اضافہ اب بلاب فیس کو 1 wei پر نہیں روک سکتا

وسائل:

• EIP-7918 تکنیکی تفصیلات (opens in a new tab)
• اسٹوری بک کی وضاحت (opens in a new tab)

اسکیل L1

ہسٹری کی میعاد ختم ہونا اور آسان رسیدیں

جولائی 2025 میں، ایتھیریم ایگزیکیوشن کلائنٹس نے جزوی ہسٹری کی میعاد ختم ہونے کی حمایت شروع کر دی (opens in a new tab)۔ اس نے دی مرج (the Merge) (opens in a new tab) سے پرانی ہسٹری کو ہٹا دیا تاکہ نوڈ آپریٹرز کے لیے درکار ڈسک اسپیس کو کم کیا جا سکے کیونکہ ایتھیریم مسلسل بڑھ رہا ہے۔

یہ EIP "Core EIPs" سے الگ ایک سیکشن میں ہے کیونکہ فورک دراصل کوئی تبدیلی نافذ نہیں کرتا - یہ ایک نوٹس ہے کہ کلائنٹ ٹیموں کو Fusaka اپ گریڈ تک ہسٹری کی میعاد ختم ہونے کی حمایت کرنی چاہیے۔ عملی طور پر، کلائنٹس اسے کسی بھی وقت نافذ کر سکتے ہیں لیکن اسے اپ گریڈ میں شامل کرنے سے یہ ٹھوس طور پر ان کی ٹو ڈو لسٹ (to-do list) میں آ گیا اور انہیں اس خصوصیت کے ساتھ مل کر Fusaka کی تبدیلیوں کو ٹیسٹ کرنے کے قابل بنایا۔

وسائل: EIP-7642 تکنیکی تفصیلات (opens in a new tab)

MODEXP کے لیے اوپری حدیں مقرر کریں

اب تک، MODEXP پری کمپائل (precompile) عملی طور پر کسی بھی سائز کے نمبرز کو قبول کرتا تھا۔ اس سے اسے ٹیسٹ کرنا مشکل، غلط استعمال کرنا آسان، اور کلائنٹ کے استحکام کے لیے خطرناک بنا دیا تھا۔ EIP-7823 ایک واضح حد مقرر کرتا ہے: ہر ان پٹ نمبر زیادہ سے زیادہ 8192 بٹس (1024 بائٹس) طویل ہو سکتا ہے۔ اس سے بڑی کسی بھی چیز کو مسترد کر دیا جاتا ہے، ٹرانزیکشن کی گیس جل جاتی ہے، اور کوئی اسٹیٹ (state) تبدیلیاں نہیں ہوتیں۔ یہ انتہائی کیسز کو ہٹاتے ہوئے حقیقی دنیا کی ضروریات کو بہت آرام سے پورا کرتا ہے جنہوں نے گیس کی حد کی منصوبہ بندی اور سیکیورٹی جائزوں کو پیچیدہ بنا دیا تھا۔ یہ تبدیلی صارف یا ڈیولپر کے تجربے کو متاثر کیے بغیر مزید سیکیورٹی اور DoS تحفظ فراہم کرتی ہے۔

وسائل: EIP-7823 تکنیکی تفصیلات (opens in a new tab)

ٹرانزیکشن گیس کی حد کی کیپ (Cap)

EIP-7825 (opens in a new tab) فی ٹرانزیکشن 16,777,216 (2^24) گیس کی کیپ (cap) کا اضافہ کرتا ہے۔ یہ بلاک گیس کی حد کو بڑھاتے وقت کسی بھی ایک ٹرانزیکشن کی بدترین صورتحال کی لاگت کو محدود کر کے فعال DoS ہارڈننگ (hardening) ہے۔ یہ توثیق اور پھیلاؤ کو ماڈل کرنا آسان بناتا ہے تاکہ ہمیں گیس کی حد بڑھا کر اسکیلنگ سے نمٹنے کی اجازت مل سکے۔

بالکل 2^24 گیس کیوں؟ یہ آج کی گیس کی حد سے آرام سے چھوٹی ہے، حقیقی کنٹریکٹ کی تعیناتیوں اور بھاری پری کمپائلز کے لیے کافی بڑی ہے، اور 2 کی پاور اسے کلائنٹس میں نافذ کرنا آسان بناتی ہے۔ یہ نیا زیادہ سے زیادہ ٹرانزیکشن سائز Pectra سے پہلے کے اوسط بلاک سائز کے مترادف ہے، جو اسے ایتھیریم پر کسی بھی آپریشن کے لیے ایک معقول حد بناتا ہے۔

وسائل: EIP-7825 تکنیکی تفصیلات (opens in a new tab)

MODEXP گیس کی لاگت میں اضافہ

MODEXP ایک پری کمپائل بلٹ ان فنکشن ہے جو ماڈیولر ایکسپونینشی ایشن (modular exponentiation) کا حساب لگاتا ہے، جو RSA دستخط کی توثیق اور پروف سسٹمز میں استعمال ہونے والی بڑے نمبروں کی ریاضی کی ایک قسم ہے۔ یہ کنٹریکٹس کو ان حسابات کو خود نافذ کیے بغیر براہ راست چلانے کی اجازت دیتا ہے۔

ڈیولپرز اور کلائنٹ ٹیموں نے MODEXP کو بلاک گیس کی حد بڑھانے میں ایک بڑی رکاوٹ کے طور پر شناخت کیا کیونکہ موجودہ گیس کی قیمتوں کا تعین اکثر اس بات کا کم اندازہ لگاتا ہے کہ کچھ ان پٹس کو کتنی کمپیوٹنگ پاور کی ضرورت ہے۔ اس کا مطلب ہے کہ MODEXP استعمال کرنے والی ایک ٹرانزیکشن پورے بلاک کو پروسیس کرنے کے لیے درکار زیادہ تر وقت لے سکتی ہے، جس سے نیٹ ورک سست ہو جاتا ہے۔

یہ EIP حقیقی کمپیوٹیشنل لاگت سے میل کھانے کے لیے قیمتوں میں درج ذیل تبدیلیاں کرتا ہے:

• کم از کم چارج کو 200 سے بڑھا کر 500 گیس کرنا اور عام لاگت کے حساب کتاب پر EIP-2565 سے ایک تہائی رعایت کو ہٹانا
• جب ایکسپونینٹ (exponent) ان پٹ بہت طویل ہو تو لاگت میں زیادہ تیزی سے اضافہ کرنا۔ اگر ایکسپونینٹ (وہ "پاور" نمبر جو آپ دوسرے آرگومنٹ کے طور پر پاس کرتے ہیں) 32 بائٹس / 256 بٹس سے لمبا ہے، تو ہر اضافی بائٹ کے لیے گیس چارج بہت تیزی سے بڑھتا ہے
• بڑے بیس (base) یا ماڈیولس (modulus) پر بھی اضافی چارج کرنا۔ دیگر دو نمبرز (بیس اور ماڈیولس) کو کم از کم 32 بائٹس فرض کیا جاتا ہے - اگر کوئی ایک بڑا ہے، تو اس کے سائز کے تناسب سے لاگت بڑھ جاتی ہے

لاگت کو اصل پروسیسنگ کے وقت سے بہتر طور پر ملا کر، MODEXP اب کسی بلاک کی توثیق میں بہت زیادہ وقت لگنے کا سبب نہیں بن سکتا۔ یہ تبدیلی ان کئی تبدیلیوں میں سے ایک ہے جن کا مقصد مستقبل میں ایتھیریم کی بلاک گیس کی حد کو محفوظ طریقے سے بڑھانا ہے۔

وسائل: EIP-7883 تکنیکی تفصیلات (opens in a new tab)

RLP ایگزیکیوشن بلاک سائز کی حد

یہ اس بات پر ایک حد (ceiling) بناتا ہے کہ ایک بلاک کتنا بڑا ہو سکتا ہے - یہ اس بات کی حد ہے کہ نیٹ ورک پر کیا بھیجا جاتا ہے اور یہ گیس کی حد سے الگ ہے، جو بلاک کے اندر کام کو محدود کرتی ہے۔ بلاک سائز کی کیپ 10 MiB ہے، جس میں کنسینسس ڈیٹا کے لیے ایک چھوٹی سی گنجائش (2 MiB) مختص کی گئی ہے تاکہ ہر چیز فٹ ہو جائے اور صفائی سے پھیل سکے۔ اگر کوئی بلاک اس سے بڑا ظاہر ہوتا ہے، تو کلائنٹس اسے مسترد کر دیتے ہیں۔ اس کی ضرورت اس لیے ہے کیونکہ بہت بڑے بلاکس کو نیٹ ورک میں پھیلنے اور تصدیق ہونے میں زیادہ وقت لگتا ہے اور یہ کنسینسس کے مسائل پیدا کر سکتے ہیں یا DoS ویکٹر کے طور پر غلط استعمال ہو سکتے ہیں۔ اس کے علاوہ، کنسینسس لیئر کی گپ شپ (gossip) پہلے ہی ~10 MiB سے زیادہ کے بلاکس کو آگے نہیں بڑھاتی، اس لیے ایگزیکیوشن لیئر کو اس حد کے ساتھ ہم آہنگ کرنے سے "کچھ نے دیکھا، دوسروں نے چھوڑ دیا" جیسی عجیب و غریب صورتحال سے بچا جا سکتا ہے۔

باریکیاں: یہ 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

اس کا مقصد بدترین صورتحال میں پھیلاؤ/توثیق کے وقت کو محدود کرنا اور کنسینسس لیئر کے گپ شپ رویے کے ساتھ ہم آہنگ کرنا ہے، جس سے گیس اکاؤنٹنگ کو تبدیل کیے بغیر ری آرگ (reorg)/DoS کے خطرے کو کم کیا جا سکے۔

وسائل: EIP-7934 تکنیکی تفصیلات (opens in a new tab)

ڈیفالٹ گیس کی حد کو 60 ملین پر سیٹ کریں

فروری 2025 میں گیس کی حد کو 30M سے بڑھا کر 36M (اور بعد میں 45M) کرنے سے پہلے، یہ قدر دی مرج (ستمبر 2022) کے بعد سے تبدیل نہیں ہوئی تھی۔ اس EIP کا مقصد مستقل اسکیلنگ کو ترجیح بنانا ہے۔

EIP-7935 EL کلائنٹ ٹیموں کو Fusaka کے لیے ڈیفالٹ گیس کی حد کو آج کے 45M سے اوپر بڑھانے کے لیے مربوط کرتا ہے۔ یہ ایک معلوماتی EIP ہے، لیکن یہ واضح طور پر کلائنٹس سے کہتا ہے کہ وہ ڈیونیٹس (devnets) پر اعلی حدود کی جانچ کریں، ایک محفوظ قدر پر متفق ہوں، اور اس نمبر کو اپنی Fusaka ریلیز میں شامل کریں۔

ڈیونیٹ کی منصوبہ بندی ~60M دباؤ (مصنوعی لوڈ کے ساتھ مکمل بلاکس) اور بتدریج اضافے کو نشانہ بناتی ہے؛ تحقیق کہتی ہے کہ بدترین صورتحال میں بلاک سائز کی خرابیاں ~150M سے نیچے نہیں ہونی چاہئیں۔ رول آؤٹ کو ٹرانزیکشن گیس کی حد کی کیپ (EIP-7825) کے ساتھ جوڑا جانا چاہیے تاکہ حدود بڑھنے پر کوئی ایک ٹرانزیکشن غلبہ حاصل نہ کر سکے۔

وسائل: EIP-7935 تکنیکی تفصیلات (opens in a new tab)

UX کو بہتر بنائیں

ڈیٹرمنسٹک پروپوزر لک آہیڈ (Deterministic proposer lookahead)

EIP-7917 کے ساتھ، بیکن چین (Beacon Chain) اگلے ایپوک (epoch) کے لیے آنے والے بلاک پروپوزرز سے آگاہ ہو جائے گی۔ اس بات پر ایک حتمی (deterministic) نظریہ رکھنا کہ کون سے ویلیڈیٹرز مستقبل کے بلاکس تجویز کریں گے، پری کنفرمیشنز (preconfirmations) (opens in a new tab) کو فعال کر سکتا ہے - آنے والے پروپوزر کے ساتھ ایک عزم جو اس بات کی ضمانت دیتا ہے کہ صارف کی ٹرانزیکشن کو اصل بلاک کا انتظار کیے بغیر ان کے بلاک میں شامل کیا جائے گا۔

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

وسائل: EIP-7917 تکنیکی تفصیلات (opens in a new tab)

کاؤنٹ لیڈنگ زیروز (CLZ) اوپ کوڈ

یہ خصوصیت ایک چھوٹی EVM ہدایت، کاؤنٹ لیڈنگ زیروز (CLZ) کا اضافہ کرتی ہے۔ EVM میں زیادہ تر ہر چیز کو 256-بٹ ویلیو کے طور پر پیش کیا جاتا ہے—یہ نیا اوپ کوڈ (opcode) بتاتا ہے کہ سامنے کتنے زیرو بٹس ہیں۔ یہ بہت سے انسٹرکشن سیٹ آرکیٹیکچرز میں ایک عام خصوصیت ہے کیونکہ یہ زیادہ موثر ریاضیاتی کارروائیوں کو قابل بناتا ہے۔ عملی طور پر یہ آج کے ہینڈ رولڈ بٹ اسکینز کو ایک قدم میں سمیٹ دیتا ہے، لہذا پہلا سیٹ بٹ تلاش کرنا، بائٹس کو اسکین کرنا، یا بٹ فیلڈز کو پارس کرنا آسان اور سستا ہو جاتا ہے۔ اوپ کوڈ کم، مقررہ لاگت والا ہے اور اسے بنیادی اضافے (add) کے برابر بینچ مارک کیا گیا ہے، جو بائٹ کوڈ کو تراشتا ہے اور اسی کام کے لیے گیس بچاتا ہے۔

وسائل: EIP-7939 تکنیکی تفصیلات (opens in a new tab)

secp256r1 کروو (Curve) سپورٹ کے لیے پری کمپائل

مقررہ ایڈریس 0x100 پر ایک بلٹ ان، پاس کی (passkey) طرز کا secp256r1 (P-256) دستخط چیکر متعارف کراتا ہے جو اسی کال فارمیٹ کا استعمال کرتا ہے جسے پہلے ہی بہت سے L2s نے اپنایا ہے اور ایج کیسز کو ٹھیک کرتا ہے، تاکہ ان ماحول کے لیے لکھے گئے کنٹریکٹس بغیر کسی تبدیلی کے L1 پر کام کریں۔

UX اپ گریڈ! صارفین کے لیے، یہ ڈیوائس-نیٹو سائننگ اور پاس کیز کو کھولتا ہے۔ والیٹس براہ راست Apple Secure Enclave، Android Keystore، ہارڈویئر سیکیورٹی ماڈیولز (HSMs)، اور FIDO2/WebAuthn تک رسائی حاصل کر سکتے ہیں - کوئی سیڈ فریز (seed phrase) نہیں، ہموار آن بورڈنگ، اور ملٹی فیکٹر فلو جو جدید ایپس کی طرح محسوس ہوتے ہیں۔ اس کے نتیجے میں بہتر UX، آسان ریکوری، اور اکاؤنٹ ایبسٹریکشن پیٹرن ملتے ہیں جو اس سے میل کھاتے ہیں جو اربوں ڈیوائسز پہلے ہی کرتی ہیں۔

ڈیولپرز کے لیے، یہ 160-بائٹ ان پٹ لیتا ہے اور 32-بائٹ آؤٹ پٹ واپس کرتا ہے، جس سے موجودہ لائبریریوں اور L2 کنٹریکٹس کو پورٹ کرنا آسان ہو جاتا ہے۔ اندرونی طور پر، اس میں پوائنٹ-ایٹ-انفینٹی اور ماڈیولر-موازنہ چیک شامل ہیں تاکہ درست کالرز کو توڑے بغیر مشکل ایج کیسز کو ختم کیا جا سکے۔

وسائل:

• EIP-7951 تکنیکی تفصیلات (opens in a new tab)
• RIP-7212 کے بارے میں مزید (opens in a new tab) (نوٹ کریں کہ EIP-7951 نے RIP-7212 کی جگہ لے لی ہے)

میٹا (Meta)

eth_config JSON-RPC طریقہ

یہ ایک JSON-RPC کال ہے جو آپ کو اپنے نوڈ سے یہ پوچھنے کی اجازت دیتی ہے کہ آپ کون سی فورک سیٹنگز چلا رہے ہیں۔ یہ تین اسنیپ شاٹس واپس کرتا ہے: current، next، اور last تاکہ ویلیڈیٹرز اور مانیٹرنگ ٹولز اس بات کی تصدیق کر سکیں کہ کلائنٹس آنے والے فورک کے لیے تیار ہیں۔

عملی طور پر، یہ اس خامی کو دور کرنے کے لیے ہے جو اس وقت دریافت ہوئی تھی جب Pectra فورک 2025 کے اوائل میں Holesky ٹیسٹ نیٹ پر معمولی غلط کنفیگریشنز کے ساتھ لائیو ہوا تھا جس کے نتیجے میں ایک نان-فائنلائزنگ اسٹیٹ (non-finalizing state) پیدا ہوئی۔ اس سے ٹیسٹنگ ٹیموں اور ڈیولپرز کو یہ یقینی بنانے میں مدد ملتی ہے کہ ڈیونیٹس سے ٹیسٹ نیٹس، اور ٹیسٹ نیٹس سے مین نیٹ (Mainnet) پر منتقل ہوتے وقت بڑے فورکس توقع کے مطابق برتاؤ کریں گے۔

اسنیپ شاٹس میں شامل ہیں: chainId، forkId، منصوبہ بند فورک ایکٹیویشن کا وقت، کون سے پری کمپائلز فعال ہیں، پری کمپائل ایڈریسز، سسٹم کنٹریکٹ انحصار، اور فورک کا بلاب شیڈول۔

یہ EIP "Core EIPs" سے الگ ایک سیکشن میں ہے کیونکہ فورک دراصل کوئی تبدیلی نافذ نہیں کرتا - یہ ایک نوٹس ہے کہ کلائنٹ ٹیموں کو Fusaka اپ گریڈ تک اس JSON-RPC طریقہ کو نافذ کرنا چاہیے۔

وسائل: EIP-7910 تکنیکی تفصیلات (opens in a new tab)

اکثر پوچھے گئے سوالات (FAQ)

کیا یہ اپ گریڈ تمام ایتھیریم نوڈز اور ویلیڈیٹرز کو متاثر کرتا ہے؟

جی ہاں، Fusaka اپ گریڈ کے لیے ایگزیکیوشن کلائنٹس اور کنسینسس کلائنٹس دونوں میں اپ ڈیٹس کی ضرورت ہوتی ہے۔ تمام اہم ایتھیریم کلائنٹس ہارڈ فورک کو سپورٹ کرنے والے ورژنز جاری کریں گے جنہیں اعلی ترجیح کے طور پر نشان زد کیا گیا ہے۔ آپ کلائنٹ GitHub ریپوز، ان کے Discord چینلز (opens in a new tab)، EthStaker Discord (opens in a new tab) میں، یا پروٹوکول اپ ڈیٹس کے لیے ایتھیریم بلاگ کو سبسکرائب کر کے اس بات سے باخبر رہ سکتے ہیں کہ یہ ریلیز کب دستیاب ہوں گی۔ اپ گریڈ کے بعد ایتھیریم نیٹ ورک کے ساتھ ہم آہنگی برقرار رکھنے کے لیے، نوڈ آپریٹرز کو یہ یقینی بنانا چاہیے کہ وہ ایک سپورٹڈ کلائنٹ ورژن چلا رہے ہیں۔ نوٹ کریں کہ کلائنٹ ریلیز کے بارے میں معلومات وقت کے لحاظ سے حساس ہیں، اور صارفین کو تازہ ترین تفصیلات کے لیے تازہ ترین اپ ڈیٹس کا حوالہ دینا چاہیے۔

ہارڈ فورک کے بعد ETH کو کیسے تبدیل کیا جا سکتا ہے؟

• آپ کے ETH کے لیے کسی کارروائی کی ضرورت نہیں: ایتھیریم Fusaka اپ گریڈ کے بعد، آپ کے ETH کو تبدیل یا اپ گریڈ کرنے کی کوئی ضرورت نہیں ہے۔ آپ کے اکاؤنٹ کے بیلنس وہی رہیں گے، اور جو ETH آپ کے پاس فی الحال ہے وہ ہارڈ فورک کے بعد اپنی موجودہ شکل میں قابل رسائی رہے گا۔
• اسکیمز سے ہوشیار رہیں! کوئی بھی جو آپ کو اپنا ETH "اپ گریڈ" کرنے کی ہدایت کر رہا ہے وہ آپ کو دھوکہ دینے کی کوشش کر رہا ہے۔ اس اپ گریڈ کے سلسلے میں آپ کو کچھ کرنے کی ضرورت نہیں ہے۔ آپ کے اثاثے مکمل طور پر غیر متاثر رہیں گے۔ یاد رکھیں، باخبر رہنا اسکیمز کے خلاف بہترین دفاع ہے۔

اسکیمز کو پہچاننے اور ان سے بچنے کے بارے میں مزید

زیبروں کا کیا چکر ہے؟

زیبرا Fusaka کا ڈیولپرز کا منتخب کردہ "میسکوٹ (mascot)" ہے کیونکہ اس کی دھاریاں PeerDAS کی کالم پر مبنی ڈیٹا کی دستیابی کی سیمپلنگ کی عکاسی کرتی ہیں، جہاں نوڈز کچھ کالم سب نیٹس کی تحویل رکھتے ہیں اور ہر پیئرز (peers) سلاٹ سے کچھ دوسرے کالمز کا نمونہ لیتے ہیں تاکہ یہ چیک کیا جا سکے کہ بلاب ڈیٹا دستیاب ہے۔

2022 میں دی مرج نے ایگزیکیوشن اور کنسینسس لیئرز کے ملنے کا اشارہ دینے کے لیے ایک پانڈا کا استعمال کیا (opens in a new tab)۔ اس کے بعد سے، ہر فورک کے لیے غیر رسمی طور پر میسکوٹس کا انتخاب کیا گیا ہے اور اپ گریڈ کے وقت کلائنٹ لاگز میں ASCII آرٹ کے طور پر ظاہر ہوتے ہیں۔ یہ جشن منانے کا صرف ایک تفریحی طریقہ ہے۔

L2 اسکیلنگ کے لیے کون سی بہتری شامل ہے؟

PeerDAS فورک کی اہم خصوصیت ہے۔ یہ ڈیٹا کی دستیابی کی سیمپلنگ (DAS) کو نافذ کرتا ہے جو رول اپس کے لیے مزید اسکیل ایبلٹی کو کھولتا ہے، نظریاتی طور پر بلاب اسپیس کو موجودہ سائز سے 8 گنا تک اسکیل کرتا ہے۔ بلاب فیس مارکیٹ کو بھی بہتر بنایا جائے گا تاکہ ہجوم پر مؤثر طریقے سے ردعمل ظاہر کیا جا سکے اور اس بات کی ضمانت دی جا سکے کہ L2s اس کمپیوٹ اور اسپیس کے لیے ایک بامعنی فیس ادا کریں جو بلابز نوڈز پر مسلط کرتے ہیں۔

BPO فورکس کیسے مختلف ہیں؟

صرف بلاب پیرامیٹر (Blob Only Parameter) فورکس PeerDAS کے فعال ہونے کے بعد بلاب کی تعداد (ہدف اور زیادہ سے زیادہ دونوں) کو مسلسل بڑھانے کا ایک طریقہ کار فراہم کرتے ہیں، بغیر کسی مکمل مربوط اپ گریڈ کا انتظار کیے۔ ہر اضافے کو Fusaka کو سپورٹ کرنے والی کلائنٹ ریلیز میں پہلے سے کنفیگر ہونے کے لیے ہارڈ کوڈ کیا گیا ہے۔

بطور صارف یا ویلیڈیٹر، آپ کو ہر BPO کے لیے اپنے کلائنٹس کو اپ ڈیٹ کرنے کی ضرورت نہیں ہے اور صرف Fusaka جیسے بڑے ہارڈ فورکس کی پیروی کو یقینی بنائیں۔ یہ پہلے جیسی ہی مشق ہے، اس کے لیے کسی خاص کارروائی کی ضرورت نہیں ہے۔ پھر بھی یہ تجویز کیا جاتا ہے کہ اپ گریڈز اور BPOs کے ارد گرد اپنے کلائنٹس کی نگرانی کریں اور انہیں بڑی ریلیز کے درمیان بھی اپ ڈیٹ رکھیں کیونکہ ہارڈ فورک کے بعد اصلاحات یا آپٹیمائزیشنز آ سکتی ہیں۔

BPO شیڈول کیا ہے؟

BPO اپ ڈیٹس کا صحیح شیڈول Fusaka ریلیز کے ساتھ طے کیا جائے گا۔ پروٹوکول کے اعلانات (opens in a new tab) اور اپنے کلائنٹس کے ریلیز نوٹس پر عمل کریں۔

یہ کیسا لگ سکتا ہے اس کی مثال:

• Fusaka سے پہلے: ہدف 6، زیادہ سے زیادہ 9
• Fusaka ایکٹیویشن پر: ہدف 6، زیادہ سے زیادہ 9
• BPO1، Fusaka ایکٹیویشن کے چند ہفتوں بعد: ہدف 10، زیادہ سے زیادہ 15، دو تہائی کا اضافہ
• BPO2، BPO1 کے چند ہفتوں بعد: ہدف 14، زیادہ سے زیادہ 21

کیا اس سے ایتھیریم (لیئر 1) پر فیس کم ہو جائے گی

یہ اپ گریڈ L1 پر گیس کی فیس کو کم نہیں کرتا، کم از کم براہ راست نہیں۔ بنیادی توجہ رول اپ ڈیٹا کے لیے زیادہ بلاب اسپیس پر ہے، اس لیے لیئر 2 پر فیس کم ہو رہی ہے۔ اس کے L1 فیس مارکیٹ پر کچھ ضمنی اثرات ہو سکتے ہیں لیکن کسی خاص تبدیلی کی توقع نہیں ہے۔

ایک اسٹیکر کے طور پر، مجھے اپ گریڈ کے لیے کیا کرنے کی ضرورت ہے؟

ہر نیٹ ورک اپ گریڈ کی طرح، اپنے کلائنٹس کو Fusaka سپورٹ کے ساتھ نشان زدہ تازہ ترین ورژنز میں اپ ڈیٹ کرنا یقینی بنائیں۔ ریلیز کے بارے میں باخبر رہنے کے لیے میلنگ لسٹ اور EF بلاگ پر پروٹوکول کے اعلانات (opens in a new tab) میں اپ ڈیٹس پر عمل کریں۔ مین نیٹ پر Fusaka کے فعال ہونے سے پہلے اپنے سیٹ اپ کی توثیق کرنے کے لیے، آپ ٹیسٹ نیٹس پر ایک ویلیڈیٹر چلا سکتے ہیں۔ Fusaka ٹیسٹ نیٹس پر جلد فعال ہو جاتا ہے (opens in a new tab) جس سے آپ کو یہ یقینی بنانے کے لیے زیادہ جگہ ملتی ہے کہ سب کچھ کام کر رہا ہے اور بگز کی اطلاع دے سکتے ہیں۔ ٹیسٹ نیٹ فورکس کا اعلان میلنگ لسٹ اور بلاگ میں بھی کیا جاتا ہے۔

کیا "ڈیٹرمنسٹک پروپوزر لک آہیڈ" (EIP-7917) ویلیڈیٹرز کو متاثر کرتا ہے؟

یہ تبدیلی آپ کے ویلیڈیٹر کلائنٹ کے کام کرنے کے طریقے کو تبدیل نہیں کرتی، تاہم، یہ آپ کے ویلیڈیٹر کے فرائض کے مستقبل کے بارے میں مزید بصیرت فراہم کرے گی۔ نئی خصوصیات کے ساتھ ہم آہنگ رہنے کے لیے اپنے مانیٹرنگ ٹولنگ کو اپ ڈیٹ کرنا یقینی بنائیں۔

Fusaka نوڈز اور ویلیڈیٹرز کے لیے بینڈوتھ کی ضروریات کو کیسے متاثر کرتا ہے؟

PeerDAS اس بات میں ایک اہم تبدیلی کرتا ہے کہ نوڈز بلاب ڈیٹا کو کیسے منتقل کرتے ہیں۔ تمام ڈیٹا کو 128 سب نیٹس میں کالمز نامی ٹکڑوں میں تقسیم کیا جاتا ہے جس میں نوڈز ان میں سے صرف کچھ کو سبسکرائب کرتے ہیں۔ سب نیٹ کالمز کی وہ مقدار جو نوڈز کو تحویل میں رکھنی ہوتی ہے ان کی کنفیگریشن اور منسلک ویلیڈیٹرز کی تعداد پر منحصر ہے۔ اصل بینڈوتھ کی ضروریات نیٹ ورک میں اجازت یافتہ بلابز کی مقدار اور نوڈ کی قسم پر منحصر ہوں گی۔ Fusaka ایکٹیویشن کے وقت بلاب کا ہدف پہلے جیسا ہی رہتا ہے، لیکن PeerDAS کے ساتھ، نوڈ آپریٹرز بلابز کے اپنے ڈسک کے استعمال اور نیٹ ورک ٹریفک میں کمی دیکھ سکتے ہیں۔ چونکہ BPOs نیٹ ورک میں زیادہ تعداد میں بلابز کو کنفیگر کرتے ہیں، اس لیے ہر BPO کے ساتھ ضروری بینڈوتھ میں اضافہ ہوگا۔

نوڈز کی ضروریات Fusaka BPOs کے بعد بھی تجویز کردہ مارجنز (opens in a new tab) کے اندر ہیں۔

فل نوڈز (Full nodes)

بغیر کسی ویلیڈیٹرز کے باقاعدہ نوڈز صرف 4 سب نیٹس کو سبسکرائب کریں گے، جو اصل ڈیٹا کے 1/8 حصے کی تحویل فراہم کریں گے۔ اس کا مطلب ہے کہ بلاب ڈیٹا کی اتنی ہی مقدار کے ساتھ، انہیں ڈاؤن لوڈ کرنے کی نوڈ بینڈوتھ آٹھ (8) گنا کم ہو جائے گی۔ ایک عام فل نوڈ کے لیے بلابز کا ڈسک کا استعمال اور ڈاؤن لوڈ بینڈوتھ تقریباً 80% کم ہو کر صرف چند Mb تک رہ سکتی ہے۔

سولو اسٹیکرز (Solo stakers)

اگر نوڈ کو ویلیڈیٹر کلائنٹ کے لیے استعمال کیا جاتا ہے، تو اسے زیادہ کالمز کی تحویل رکھنی ہوتی ہے اور اس لیے زیادہ ڈیٹا پروسیس کرنا ہوتا ہے۔ ایک ویلیڈیٹر شامل ہونے کے ساتھ، نوڈ کم از کم 8 کالم سب نیٹس کو سبسکرائب کرتا ہے اور اس لیے باقاعدہ نوڈ سے دوگنا ڈیٹا پروسیس کرتا ہے لیکن پھر بھی Fusaka سے کم۔ اگر ویلیڈیٹر کا بیلنس 287 ETH سے زیادہ ہے، تو زیادہ سے زیادہ سب نیٹس کو سبسکرائب کیا جائے گا۔

ایک سولو اسٹیکر کے لیے، اس کا مطلب ہے کہ ان کا ڈسک کا استعمال اور ڈاؤن لوڈ بینڈوتھ تقریباً 50% کم ہو جائے گی۔ تاہم مقامی طور پر بلاکس بنانے اور تمام بلابز کو نیٹ ورک پر اپ لوڈ کرنے کے لیے، زیادہ اپ لوڈ بینڈوتھ کی ضرورت ہوتی ہے۔ مقامی بلڈرز کو Fusaka کے وقت پہلے سے 2-3 گنا زیادہ اپ لوڈ بینڈوتھ کی ضرورت ہوگی اور 15/21 بلابز کے BPO2 ہدف کے ساتھ، حتمی ضروری اپ لوڈ بینڈوتھ تقریباً 5 گنا زیادہ، 100Mpbs پر ہونی چاہیے۔

بڑے ویلیڈیٹرز

سبسکرائب شدہ سب نیٹس کی تعداد نوڈ میں مزید بیلنس اور ویلیڈیٹرز شامل ہونے کے ساتھ بڑھتی ہے۔ مثال کے طور پر، تقریباً 800 ETH بیلنس پر، نوڈ 25 کالمز کی تحویل رکھتا ہے اور اسے پہلے سے تقریباً 30% زیادہ ڈاؤن لوڈ بینڈوتھ کی ضرورت ہوگی۔ ضروری اپ لوڈ باقاعدہ نوڈز کی طرح بڑھتا ہے اور کم از کم 100Mbps ضروری ہے۔

4096 ETH، 2 زیادہ سے زیادہ بیلنس ویلیڈیٹرز پر، نوڈ 'سپرنوڈ (supernode)' بن جاتا ہے جو تمام کالمز کی تحویل رکھتا ہے، اس لیے ہر چیز کو ڈاؤن لوڈ اور اسٹور کرتا ہے۔ یہ نوڈز غائب ڈیٹا کو واپس دے کر نیٹ ورک کو فعال طور پر ٹھیک کرتے ہیں لیکن انہیں بہت زیادہ بینڈوتھ اور اسٹوریج کی بھی ضرورت ہوتی ہے۔ حتمی بلاب ہدف پہلے سے 6 گنا زیادہ ہونے کے ساتھ، سپر نوڈز کو تقریباً 600GB اضافی بلاب ڈیٹا اسٹور کرنا ہوگا اور ان کے پاس تقریباً 20Mbps پر تیز تر پائیدار ڈاؤن لوڈ بینڈوتھ ہونی چاہیے۔

متوقع ضروریات پر مزید تفصیلات پڑھیں۔ (opens in a new tab)

کون سی EVM تبدیلیاں نافذ کی گئی ہیں؟

Fusaka نئی معمولی تبدیلیوں اور خصوصیات کے ساتھ EVM کو مستحکم کرتا ہے۔

• اسکیلنگ کے دوران سیکیورٹی کے لیے، ایک ٹرانزیکشن کا زیادہ سے زیادہ سائز گیس کی 16.7 ملین اکائیوں تک محدود (opens in a new tab) ہوگا۔
• نیا اوپ کوڈ کاؤنٹ لیڈنگ زیروز (CLZ) (opens in a new tab) EVM میں شامل کیا گیا ہے اور یہ اسمارٹ کنٹریکٹ زبانوں کو کچھ کارروائیوں کو زیادہ مؤثر طریقے سے انجام دینے کے قابل بنائے گا۔
• ModExp پری کمپائل کی لاگت میں اضافہ کیا جائے گا (opens in a new tab)—اسے استعمال کرنے والے کنٹریکٹس ایگزیکیوشن کے لیے زیادہ گیس چارج کریں گے۔

نئی 16M گیس کی حد کنٹریکٹ ڈیولپرز کو کیسے متاثر کرتی ہے؟

Fusaka ایک ٹرانزیکشن کے زیادہ سے زیادہ سائز کو 16.7 ملین (opens in a new tab) (2^24) گیس یونٹس تک محدود کرتا ہے۔ یہ تقریباً ایک اوسط بلاک کا پچھلا سائز ہے جو اسے اتنی بڑی بناتا ہے کہ وہ پیچیدہ ٹرانزیکشنز کو ایڈجسٹ کر سکے جو پورے بلاک کو استعمال کر لیں۔ یہ حد کلائنٹس کے لیے تحفظ پیدا کرتی ہے، مستقبل میں زیادہ بلاک گیس کی حد کے ساتھ ممکنہ DoS حملوں کو روکتی ہے۔ اسکیلنگ کا مقصد زیادہ ٹرانزیکشنز کو بلاک چین میں شامل ہونے کے قابل بنانا ہے بغیر کسی ایک کے پورے بلاک کو استعمال کیے۔

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

RPC طریقہ eth_call محدود نہیں ہے اور اصل بلاک چین کی حد سے بڑی ٹرانزیکشنز کی سیمولیشن کی اجازت دے گا۔ غلط استعمال کو روکنے کو یقینی بنانے کے لیے کلائنٹ آپریٹر کے ذریعے RPC طریقوں کی اصل حد کو کنفیگر کیا جا سکتا ہے۔

ڈیولپرز کے لیے CLZ کا کیا مطلب ہے؟

Solidity جیسے EVM کمپائلرز اندرونی طور پر زیروز گننے کے لیے نئے فنکشن کو نافذ اور استعمال کریں گے۔ نئے کنٹریکٹس گیس کی بچت سے فائدہ اٹھا سکتے ہیں اگر وہ اس قسم کے آپریشن پر انحصار کرتے ہیں۔ ممکنہ بچت پر دستاویزات کے لیے اسمارٹ کنٹریکٹ زبان کی ریلیز اور فیچر کے اعلانات پر عمل کریں۔

کیا میرے موجودہ اسمارٹ کنٹریکٹس کے لیے کوئی تبدیلیاں ہیں؟

Fusaka کا کوئی براہ راست اثر نہیں ہے جو کسی موجودہ کنٹریکٹس کو توڑ دے یا ان کے رویے کو تبدیل کرے۔ ایگزیکیوشن لیئر میں متعارف کرائی گئی تبدیلیاں بیک ورڈ کمپیٹیبلٹی (backward compatibility) کے ساتھ کی گئی ہیں، تاہم، ہمیشہ ایج کیسز اور ممکنہ اثرات پر نظر رکھیں۔

ModExp پری کمپائل کی لاگت میں اضافے کے ساتھ (opens in a new tab)، اس پر انحصار کرنے والے کنٹریکٹس ایگزیکیوشن کے لیے زیادہ گیس استعمال کریں گے۔ اگر آپ کا کنٹریکٹ اس پر بہت زیادہ انحصار کرتا ہے اور صارفین کے لیے زیادہ مہنگا ہو جاتا ہے، تو اس کے استعمال کے طریقے پر دوبارہ غور کریں۔

اگر آپ کے کنٹریکٹس کو انجام دینے والی ٹرانزیکشنز اسی طرح کے سائز تک پہنچ سکتی ہیں تو نئی 16.7 ملین کی حد (opens in a new tab) پر غور کریں۔

مزید مطالعہ

• ایتھیریم روڈ میپ
• Forkcast: Fusaka (opens in a new tab)
• Fusaka Meta EIP (opens in a new tab)
• Fusaka ٹیسٹ نیٹ بلاگ کا اعلان (opens in a new tab)
• Bankless: Fusaka اور Pectra ایتھیریم کے لیے کیا لائیں گے (opens in a new tab)
• Bankless: ایتھیریم کے اگلے اپ گریڈز: Fusaka، Glamsterdam اور اس سے آگے Preston Van Loon کے ساتھ (opens in a new tab)
• The Fusaka Files (opens in a new tab)
• PEEPanEIPs کی وضاحت (opens in a new tab)

صفحہ کی آخری اپ ڈیٹ: ۲۳ فروری، ۲۰۲۶

a (opens in a new tab)

J (opens in a new tab)

c (opens in a new tab)

+5

تعاون کنندگان دیکھیں