27 فروری 2026 کو، ویتالیک بٹرین نے Ethereum Research پر "Hyper-scaling state by creating new forms of state" کے عنوان سے ایک لمبا مضمون شائع کیا۔
اس مضمون میں، وٹالک بٹیرن نے ایتھریم کے اسکیلنگ راستے کو مزید واضح کیا۔ یہ مضمون صرف تکنیکی نقطہ نظر سے ایتھریم کے اسکیلنگ کے بارے میں نہیں بلکہ ایک مکمل ساختی نقطہ نظر سے، ایتھریم کو آنے والے کچھ سالوں تک نیٹ ورک کی صلاحیت بڑھانے کے لیے مرحلہ وار منصوبہ پیش کرتا ہے۔
اسی طرح، اس نے ایک ٹویٹ بھی X پر شائع کی جس میں اس مضمون کی مزید وضاحت کی گئی۔ ہم یہ سمجھنے کی کوشش کر رہے ہیں کہ وٹالک کا اس بار پیش کیا گیا نیا اسکیل ہو رہا حل کیا ہے اور اسے اپنانا ضروری کیوں ہے۔
short-term and long-term expansion of execution resources and data resources
ویتالیک نے لمبے مضمون کے آغاز میں اشارہ کیا کہ، "اگلے پانچ سالوں میں ایتھریم کو وسعت دینے کے لیے تین وسائل کو وسعت دینے کی ضرورت ہے":
- وسائل انجام: EVM کمپوٹیشن، دستخط کی تصدیق وغیرہ
- ڈیٹا وسائل: ٹرانزیکشن کے بھیجनے والے، وصول کنندہ، دستخط وغیرہ
- حالت کے وسائل: اکاؤنٹ باقیات، کوڈ، ذخیرہ
پہلے دو کے لیے مختصر اور طویل مدتی توسیع کے منصوبے ہیں۔
عملیاتی وسائل کے لیے، مختصر مدت میں بلاک ایکسس لسٹ (BAL)، ePBS اور گیس فیس ری پرائسنگ کے ذریعے 10-30 گنا اضافہ، اور طویل مدت میں ZK-EVM کے ذریعے تقریباً 1000 گنا اضافہ حاصل کیا جائے گا، اور کچھ خاص قسم کے کمپوٹیشنز (دستخط، SNARK/STARK) کے لیے آف چین ایگریگیشن سے کارکردگی تقریباً 10000 گنا بڑھ سکتی ہے۔
ڈیٹا وسائل کے لیے، مختصر مدت میں P2P میں بہتری اور متعدد ابعاد والے گیس کے ذریعے 10-20 گنا کا اضافہ، اور طویل مدت میں Blobs + PeerDAS کے ذریعے تقریباً 500 گنا کا اضافہ حاصل ہوگا۔
مختصر مدت کے لیے وسعت کا مقصد ایتھریم کو زیادہ تیز چلانا ہے۔ اب ایتھریم آہستہ ہے کیونکہ موجودہ تصدیق کا طریقہ ترتیبی ہے — ٹرانزیکشنز کو ایک کے بعد ایک چیک کیا جاتا ہے۔ اگر کوئی ٹرانزیکشن پھنس جائے، تو پوری تصدیق کا عمل پھنس جاتا ہے۔
اس لیے اس سال کے Glamsterdam اپگریڈ کے بعد، بلاک ایکسیس لسٹ (BAL) اور ePBS شائع کیے جائیں گے۔
بلاک ایکسس لسٹ سے بلاک بند کرنے والے گواہوں کو پہلے سے معلومات ملتی ہیں کہ "اس بلاک میں موجود ٹرانزیکشنز ان اکاؤنٹس اور اسٹوریج لوکیشنز کو ایکسس کریں گے۔" اس معلومات کے ساتھ، گواہ پہلے سے تیاری کر سکتے ہیں اور ان ڈیٹا کو ہارڈ ڈرائیو سے میموری میں لوڈ کر سکتے ہیں۔ پھر، گواہ متعدد ٹرانزیکشنز کو ایک ایک کر کے نہیں، بلکہ ایک ساتھ متوازی طور پر چیک کر سکتے ہیں۔ جیسے کہ فیکٹری کی اسٹریم لائن: پہلے ایک مزدور پورے پروڈکٹ کو انجام دیتا تھا، اب متعدد مزدور مختلف حصوں پر ایک ساتھ کام کر رہے ہیں۔
ePBS اس بات کو الگ کرتا ہے کہ بلاک کیسے بنائے جائیں اور کیسے تصدیق کیے جائیں — بلاک بنانے والے ٹرانزیکشنز کو اکٹھا کرتے ہیں، پیش کرنے والے بلاک کی پیشکش کرتے ہیں، اور ویریفائرز بلاک کی تصدیق کرتے ہیں۔ ہر کردار اپنا کام کرتا ہے، اس طرح بلاک بنانے والے زیادہ تر ٹرانزیکشنز کو زیادہ جرات سے اکٹھا کر سکتے ہیں، کیونکہ پیش کرنے والے اور ویریفائرز ان کی تصدیق کریں گے، اور انہیں سیکورٹی کے معاملات کی فکر نہیں کرنی پڑے گی۔
گیس فیس کی دوبارہ قیمت گذاری + متعدد ابعاد والی گیس شاید «مرکزی حربہ» کہلائے جا سکتی ہے۔ اب، ایتھریم کے تمام آپریشنز ایک ہی گیس فیس کا استعمال کرتے ہیں۔ لیکن وٹالک کا خیال ہے کہ مختلف آپریشنز کے لیے مختلف قیمتیں ہونی چاہئیں۔
خاص طور پر، نئی حالتیں بنانے (جیسے نیا اکاؤنٹ بنانا، نیا کنٹریکٹ ڈپلوی کرنا) کے لیے خاص "حالت بنانے کا فیس" ہونا چاہیے۔ کیونکہ نئی حالت بنانا سب سے مہنگا آپریشن ہے۔ یہ نہ صرف کمپیوٹنگ وسائل کو استعمال کرتا ہے بلکہ اسٹوریج وسائل بھی استعمال کرتا ہے۔ اور یہ لاگت مستقل ہوتی ہے — ایک بار بننے کے بعد، یہ حالت ہمیشہ کے لیے موجود رہتی ہے۔
تو، ویتالک کا خیال یہ ہے کہ نئی حالت بنانے کا خرچ زیادہ کریں، لیکن عام ٹرانزیکشنز کا خرچ کم کریں۔
اس کا طریقہ "جھیل مکانیم" ہے۔ دو بارلیاں سوچیں، ایک بارلی "حالت تشکیل فیس" کے لیے اور دوسری بارلی "عام گیس فیس" کے لیے۔ جب معاہدے ایک دوسرے کو بلاتے ہیں، تو گیس دونوں بارلیوں سے خودکار طور پر ادھار لی جاتی ہے تاکہ کوئی بگاڑ نہ ہو۔
عام صارفین کے ٹریڈز سستے ہو جائیں گے کیونکہ ان ٹریڈز پر "حالت تشکیل فیس" نہیں لگے گی۔ جبکہ نئی حالت بنانے والے ڈویلپرز کو زیادہ فیس ادا کرنی ہوگی۔ اس طرح، نیٹ ورک کی کل صلاحیت میں بڑی کاؤنٹر ہوگی، لیکن حالت کا اضافہ کنٹرول میں رہے گا اور فول نوڈس کے ہارڈ ڈرائیوز کو بھرنا نہیں پڑے گا۔
طویل مدتی وسعت کے لیے مین نیٹ کو خود مضبوط بنانا ہے اور لیئر 2 پر انحصار کم کرنا۔ اس میں بلابس + پیئرڈاس اور ZK-EVM کا مرحلہ وار اطلاق شamil ہے۔
بلوبز، جو ایک عارضی بڑی فائل اسٹوریج ہے، اب اکثر لیئر 2 کے لیے استعمال ہوتی ہے۔ مستقبل میں، ایتھریم مین نیٹ ورک خود بھی ڈیٹا محفوظ کرنے کے لیے بلوبز کا استعمال کرے گا۔ لیکن اس کے ساتھ ایک مسئلہ بھی پیدا ہوتا ہے — اگر ہر نوڈ کو تمام بلوبز ڈاؤن لوڈ کرنے پڑیں، تو نیٹ ورک بھر جائے گا۔
یہاں PeerDAS کا کردار ہوگا — آپ کو تمام ڈیٹا ڈاؤن لوڈ کرنے کی ضرورت نہیں، صرف ایک چھوٹا حصہ ڈاؤن لوڈ کرنا ہوگا۔ جیسے سیmplified سروے میں، آپ کو ہر کسی سے نہیں پوچھنا پڑتا، صرف ایک چھوٹے گروپ سے پوچھ کر پورے گروپ کی حالت کا اندازہ لگایا جا سکتا ہے۔ ZK ثبوت کے ساتھ ملا کر، جب آپ صرف تمام ڈیٹا کا 1/16 ہی ڈاؤن لوڈ کریں، تو بھی آپ ڈیٹا کی مکملیت کی تصدیق کر سکتے ہیں۔
پھر ZK-EVM کا مرحلہ وار اطلاق ہے، جس سے ایک بلاک کی تصدیق کے لیے بلاک میں موجود تمام لین دین کو دوبارہ انجام دینے کی ضرورت نہیں رہتی، نوڈس صرف ZK ثبوت پر اعتماد کر سکتے ہیں، اور تصدیق کا خرچ "تمام لین دین کو انجام دینا" سے "ایک ZK ثبوت کی تصدیق کرنا" تک کم ہو جاتا ہے۔
ویتالک کا منصوبہ ہے کہ 2026 میں، کچھ نوڈز ZK تصدیق کا تجربہ کریں گے۔ 2027 تک، مزید نوڈز کو استعمال کرنے کے لیے متوجہ کیا جائے گا۔ آخر میں، ایک بلاک کے مؤثر ہونے کے لیے، مختلف ثبوت نظاموں سے 5 قسم کے ثبوت میں سے 3 درکار ہوں گے۔ وہ توقع کرتے ہیں کہ تمام نوڈز (انڈیکس نوڈز کے علاوہ) آخرکار ZK-EVM ثبوت پر منحصر ہو جائیں گے۔
کوئی “جادوئی دوا” نہیں ہے، حالت کا اضافہ
اب دیکھتے ہیں کہ مختصر مدت اور طویل مدت کے وسعت کے بارے میں اب تک نہیں بات کی گئی "حالت کے وسائل"۔ جبکہ مختصر مدت میں، بلاک ایکسیس لسٹ کے ساتھ ہم آہنگی، p2p میں بہتری اور ڈیٹا بیس کے بہترین طریقے کے ذریعے 5-30 گنا تک بہتری حاصل کی جا سکتی ہے، لیکن طویل مدت میں؟
ویتالک کا جواب ہے، نہیں۔
کیوں اسٹیٹ ریسورسز کو ایسے مشکل سے اسکیل کیا جا سکتا ہے؟ ایتھریم کی اسٹیٹ ایک بہت بڑا ڈیٹا بیس کی طرح ہے۔ اس ڈیٹا بیس میں تمام اکاؤنٹس کے بیلنس، تمام کنٹریکٹس کا کوڈ، اور تمام اسٹوریج لوکیشنز کا ڈیٹا محفوظ ہے۔
ابھی یہ ڈیٹا بیس چھوٹا ہے، صرف تقریباً 100 GB ہے، لیکن اگر حالت کو 20 گنا کر دیا جائے تو 2 TB ہو جائے گا۔ اگر زیادہ وقت گزر جائے تو؟ 8 TB؟
مسئلہ ہارڈ ڈسک میں جگہ نہ ہونے کا نہیں، بلکہ یہ ہے:
- ڈیٹا بیس کی کارکردگی متاثر ہو رہی ہے: جدید ڈیٹا بیسز ڈیٹا کو منظم کرنے کے لیے درخت کی ساخت (مثلاً Merkle درخت) استعمال کرتی ہیں۔ جب نیا ڈیٹا لکھا جاتا ہے، تو پورے درخت کو اپڈیٹ کرنے کی ضرورت ہوتی ہے۔ اس کا مطلب یہ ہے کہ اگر آپ X بار اپڈیٹ کرنا چاہتے ہیں، تو ڈیٹا بیس کے سطح پر X بار آپریشن ہوں گے، نہ کہ صرف ایک بار اپڈیٹ کرکے ڈیٹا بیس آپریشن ایک بار مکمل کر دے۔ اپڈیٹز زیادہ ہوں گے، آپریشنز بھی زیادہ ہوں گے، اور لکھنے کی رفتار دھماکے جیسی سست ہو جائے گی۔
- مطابقت کی دشواری: ایتھریم نیٹ ورک میں شامل ہونے والے ایک نئے نوڈ کو نئے بلاکس کی تصدیق کے لیے پورا اسٹیٹ ڈاؤن لوڈ کرنا ہوگا۔ اگر ڈیٹا کا سائز 8 ٹیرا باٹ ہو جائے، تو زیادہ تر لوگوں کی موجودہ انٹرنیٹ رفتار سے بہت لمبا وقت لگے گا۔
حل موجود ہیں، لیکن وٹالک کے خیال میں ان سب میں مسائل ہیں:
- "طاقتور حالت کی بے حالتی": نوڈس کو مکمل حالت محفوظ رکھنے کی ضرورت نہیں، صرف صارفین کو مرکل ثبوت فراہم کرنے کی ضرورت ہے۔ ویتالیک کا خیال ہے کہ اس منصوبے میں حالت کے محفوظ کرنے کا مرکزیکرنا، ڈائنانمک حالت تک رسائی کی وجہ سے ٹرانزیکشن ناکام ہونا، اور بینڈ ویتھ لاگت کے مسائل موجود ہیں۔
- "حالت ختم ہو چکی": اکثر استعمال نہ ہونے والی حالتیں خودکار طور پر فعال حالت سے حذف کر دی جاتی ہیں۔ نوڈس کو صرف حالیہ طور پر ایکسیس کی گئی حالتیں محفوظ رکھنی ہوتی ہیں، جس سے ذخیرہ کی جگہ میں بڑا کمی آ جاتا ہے۔ وٹالک کا خیال ہے کہ ایک بنیادی "مسئلہ" موجود ہے، جس میں نئی حالت بناتے وقت یہ ثابت کرنا ہوتا ہے کہ کوئی حالت "کبھی موجود نہیں تھی"۔ فرض کریں کہ آپ ایک نیا اکاؤنٹ بنارہے ہیں، تو آپ کو ثابت کرنا ہوگا کہ نئے اکاؤنٹ کا پتہ ایتھریم پر کبھی بنایا نہیں گیا تھا۔ اس کا مطلب ہے کہ ہر نئے اکاؤنٹ کے بنانے کے لیے 10 سال کے تاریخی ڈیٹا کو چیک کرنا پڑے گا، جس سے نئے اکاؤنٹ بنانا پیچیدہ اور مہنگا ہو جائے گا۔
ویتالیک کا آخری طریقہ یہ ہے کہ دونوں منصوبوں کو ملا کر ایتھریم کی حالت کے وسائل کے ڈھانچے میں مجموعی تبدیلی کے طور پر کچھ نئی حالتیں پیش کرے:
- عارضی ذخیرہ: ایک ایسا ذخیرہ جو خودکار طور پر ختم ہو جاتا ہے۔ مثلاً، ایک نیا درخت بنایا جا سکتا ہے جو ہر ماہ خودکار خالی ہو جائے۔ اس ذخیرے کا استعمال عارضی ڈیٹا، آرڈر بُک، لیکویڈٹی پول، عارضی کاؤنٹرز وغیرہ کے لیے کیا جا سکتا ہے جن کا مستقل طور پر ذخیرہ کرنے کی ضرورت نہیں ہوتی؛ ایک ماہ بعد، پرانے آرڈرز ختم ہو جاتے ہیں اور نئے لیکویڈٹی پول بن جاتے ہیں۔
- دورانیہ میں ذخیرہ کرنا: عارضی ذخیرہ کرنا کی طرح، لیکن زیادہ لمبا دورانیہ، جیسے 1 سال۔
- محدود ذخیرہ: کچھ ذخیرہ صرف خاص طریقے سے ہی تک پہنچا جا سکتا ہے۔ مثال کے طور پر، ایک ERC20 ٹوکن کا باقیہ ذخیرہ، شاید صرف ایک خاص انٹرفیس کے ذریعے تک پہنچا جا سکتا ہے۔ اس طرح، نظام اس ذخیرہ کو بہتر بنانے کے قابل ہو جاتا ہے۔
اسی طرح، موجودہ حالت کو برقرار رکھیں۔ اس طرح، انجام دینا 1000 گنا سستا ہو سکتا ہے (ZK-EVM کے ذریعے)، لیکن نئی حالت کا ایجاد صرف 20 گنا سستا ہو سکتا ہے۔
ویتالیک کا خیال ہے کہ نئے حالت کے فارمیٹ کے ساتھ، ڈیولپرز کے پاس انتخاب ہے۔ موجودہ حالت کے فارمیٹ کو جاری رکھنا، لیکن زیادہ فیس ادا کرنا، یا اپلیکیشن کو دوبارہ ڈیزائن کرنا تاکہ نئے حالت کے فارمیٹ کا استعمال کیا جا سکے اور کم فیس حاصل کی جا سکے۔ عام استعمال کے معاملات (جیسے ERC20 بیلنس، NFT) کے لیے معیاری ورکفلو ہوں گے، جبکہ زیادہ پیچیدہ استعمال کے معاملات (جیسے DeFi) کے لیے ڈیولپرز کو اپنے آپ کو بہتر بنانے کا طریقہ تلاش کرنا ہوگا۔
یہ حکمت عملی کافی دلچسپ ہے، جس میں ڈویلپرز کا دماغ استعمال کرکے لاگت کم کرنے اور عادی ایتھریم صارفین کو فائدہ پہنچانے کا احساس ہے۔
لیو دونگ BlockBeats کے خالی پوسٹس کے بارے میں جاننے کے لیے کلک کریں
لیکٹ میشن BlockBeats کے آفیشل سوشل گروپ میں شامل ہوں:
ٹیلیگرام سبسکرائپ گروپ:https://t.me/theblockbeats
ٹیلیگرام گروپ:https://t.me/BlockBeats_App
ٹویٹر کا باضابطہ اکاؤنٹ:https://twitter.com/BlockBeatsAsia

