اسٹیٹ لیسنیس، اسٹیٹ کی میعاد ختم ہونا اور ہسٹری کی میعاد ختم ہونا
معمولی ہارڈویئر پر Ethereum نوڈز چلانے کی صلاحیت حقیقی ڈی سینٹرلائزیشن کے لیے انتہائی اہم ہے۔ اس کی وجہ یہ ہے کہ نوڈ چلانے سے صارفین کو یہ صلاحیت ملتی ہے کہ وہ کسی تیسرے فریق پر ڈیٹا فراہم کرنے کے لیے بھروسہ کرنے کے بجائے آزادانہ طور پر کرپٹوگرافک چیکس انجام دے کر معلومات کی تصدیق کر سکیں۔ نوڈ چلانے سے صارفین کسی درمیانی فریق پر بھروسہ کیے بغیر براہ راست Ethereum پیئر ٹو پیئر نیٹ ورک پر ٹرانزیکشنز جمع کروا سکتے ہیں۔ ڈی سینٹرلائزیشن اس وقت تک ممکن نہیں جب تک یہ فوائد صرف مہنگے ہارڈویئر والے صارفین کو دستیاب ہوں۔ اس کے بجائے، نوڈز کو انتہائی معمولی پروسیسنگ اور میموری کی ضروریات کے ساتھ چلنے کے قابل ہونا چاہیے تاکہ وہ موبائل فونز، مائیکرو کمپیوٹرز یا ہوم کمپیوٹر پر بغیر کسی رکاوٹ کے چل سکیں۔
آج، ڈسک اسپیس کی زیادہ ضروریات نوڈز تک عالمی رسائی میں سب سے بڑی رکاوٹ ہیں۔ یہ بنیادی طور پر Ethereum کے اسٹیٹ ڈیٹا کے بڑے حصوں کو اسٹور کرنے کی ضرورت کی وجہ سے ہے۔ اس اسٹیٹ ڈیٹا میں نئے بلاکس اور ٹرانزیکشنز کو درست طریقے سے پروسیس کرنے کے لیے درکار اہم معلومات شامل ہوتی ہیں۔ اس تحریر کے وقت، ایک مکمل Ethereum نوڈ چلانے کے لیے ایک تیز 2TB SSD کی سفارش کی جاتی ہے۔ ایک ایسے نوڈ کے لیے جو کسی پرانے ڈیٹا کو ختم (prune) نہیں کرتا، اسٹوریج کی ضرورت تقریباً 14GB/ہفتہ کی شرح سے بڑھتی ہے، اور آرکائیو نوڈز جو جینیسس (genesis) سے لے کر اب تک کا تمام ڈیٹا اسٹور کرتے ہیں، 12 TB کے قریب پہنچ رہے ہیں (اس تحریر کے وقت، فروری 2023 میں)۔
پرانے ڈیٹا کو اسٹور کرنے کے لیے سستی ہارڈ ڈرائیوز استعمال کی جا سکتی ہیں لیکن وہ آنے والے بلاکس کے ساتھ رفتار برقرار رکھنے کے لیے بہت سست ہوتی ہیں۔ کلائنٹس کے لیے موجودہ اسٹوریج ماڈلز کو برقرار رکھتے ہوئے ڈیٹا کو سستا اور اسٹور کرنے میں آسان بنانا اس مسئلے کا صرف ایک عارضی اور جزوی حل ہے کیونکہ Ethereum کی اسٹیٹ کی نمو 'لامحدود' ہے، جس کا مطلب ہے کہ اسٹوریج کی ضروریات ہمیشہ بڑھتی ہی رہیں گی، اور تکنیکی بہتریوں کو ہمیشہ مسلسل اسٹیٹ کی نمو کے ساتھ رفتار برقرار رکھنی ہوگی۔ اس کے بجائے، کلائنٹس کو بلاکس اور ٹرانزیکشنز کی تصدیق کے لیے نئے طریقے تلاش کرنے ہوں گے جو مقامی ڈیٹا بیس سے ڈیٹا تلاش کرنے پر انحصار نہ کریں۔
نوڈز کے لیے اسٹوریج کو کم کرنا
ہر نوڈ کو اسٹور کیے جانے والے ڈیٹا کی مقدار کو کم کرنے کے کئی طریقے ہیں، جن میں سے ہر ایک کے لیے Ethereum کے بنیادی پروٹوکول کو مختلف حد تک اپ ڈیٹ کرنے کی ضرورت ہوتی ہے:
- ہسٹری کی میعاد ختم ہونا (History expiry): نوڈز کو X بلاکس سے پرانے اسٹیٹ ڈیٹا کو ضائع کرنے کے قابل بناتا ہے، لیکن اس سے یہ تبدیل نہیں ہوتا کہ Ethereum کلائنٹس اسٹیٹ ڈیٹا کو کیسے ہینڈل کرتے ہیں۔
- اسٹیٹ کی میعاد ختم ہونا (State expiry): ایسے اسٹیٹ ڈیٹا کو غیر فعال ہونے کی اجازت دیتا ہے جو کثرت سے استعمال نہیں ہوتا۔ غیر فعال ڈیٹا کو کلائنٹس اس وقت تک نظر انداز کر سکتے ہیں جب تک کہ اسے دوبارہ زندہ (resurrect) نہ کیا جائے۔
- کمزور اسٹیٹ لیسنیس (Weak statelessness): صرف بلاک پروڈیوسرز کو مکمل اسٹیٹ ڈیٹا تک رسائی کی ضرورت ہوتی ہے، دیگر نوڈز مقامی اسٹیٹ ڈیٹا بیس کے بغیر بلاکس کی تصدیق کر سکتے ہیں۔
- مضبوط اسٹیٹ لیسنیس (Strong statelessness): کسی بھی نوڈ کو مکمل اسٹیٹ ڈیٹا تک رسائی کی ضرورت نہیں ہوتی۔
ڈیٹا کی میعاد ختم ہونا
ہسٹری کی میعاد ختم ہونا
ہسٹری کی میعاد ختم ہونے سے مراد کلائنٹس کا اس پرانے ڈیٹا کو ختم (prune) کرنا ہے جس کی انہیں ضرورت پڑنے کا امکان نہیں ہے، تاکہ وہ صرف تھوڑی مقدار میں تاریخی ڈیٹا اسٹور کریں، اور نیا ڈیٹا آنے پر پرانے ڈیٹا کو چھوڑ دیں۔ کلائنٹس کو تاریخی ڈیٹا کی ضرورت دو وجوہات کی بنا پر ہوتی ہے: سنکنگ (syncing) اور ڈیٹا کی درخواستوں کو پورا کرنا۔ اصل میں، کلائنٹس کو جینیسس بلاک سے سنک کرنا پڑتا تھا، اور چین کے ہیڈ (head) تک ہر یکے بعد دیگرے آنے والے بلاک کے درست ہونے کی تصدیق کرنی پڑتی تھی۔ آج، کلائنٹس چین کے ہیڈ تک پہنچنے کے لیے "weak subjectivity checkpoints" کا استعمال کرتے ہیں۔ یہ چیک پوائنٹس قابل اعتماد شروعاتی مقامات ہیں، جیسے کہ Ethereum کے بالکل آغاز کے بجائے موجودہ وقت کے قریب ایک جینیسس بلاک کا ہونا۔ اس کا مطلب ہے کہ کلائنٹس چین کے ہیڈ تک سنک کرنے کی صلاحیت کھوئے بغیر حالیہ ترین weak subjectivity checkpoint سے پہلے کی تمام معلومات کو چھوڑ سکتے ہیں۔ کلائنٹس فی الحال تاریخی ڈیٹا کے لیے (JSON-RPC کے ذریعے آنے والی) درخواستوں کو اپنے مقامی ڈیٹا بیس سے حاصل کر کے پورا کرتے ہیں۔ تاہم، ہسٹری کی میعاد ختم ہونے کے ساتھ یہ ممکن نہیں ہوگا اگر درخواست کردہ ڈیٹا کو ختم کر دیا گیا ہو۔ اس تاریخی ڈیٹا کو فراہم کرنے کے لیے کچھ اختراعی حل درکار ہیں۔
ایک آپشن یہ ہے کہ کلائنٹس Portal Network جیسے حل کا استعمال کرتے ہوئے پیئرز (peers) سے تاریخی ڈیٹا کی درخواست کریں۔ Portal Network تاریخی ڈیٹا فراہم کرنے کے لیے ایک زیرِ ترقی پیئر ٹو پیئر نیٹ ورک ہے جہاں ہر نوڈ Ethereum کی ہسٹری کا ایک چھوٹا سا حصہ اسٹور کرتا ہے تاکہ پوری ہسٹری نیٹ ورک میں تقسیم شدہ حالت میں موجود رہے۔ متعلقہ ڈیٹا کو اسٹور کرنے والے پیئرز کو تلاش کر کے اور ان سے درخواست کر کے درخواستیں پوری کی جاتی ہیں۔ متبادل کے طور پر، چونکہ عام طور پر ایپس کو تاریخی ڈیٹا تک رسائی کی ضرورت ہوتی ہے، اس لیے اسے اسٹور کرنا ان کی ذمہ داری بن سکتی ہے۔ Ethereum اسپیس میں اتنے رضاکار (altruistic) اداکار بھی ہو سکتے ہیں جو تاریخی آرکائیوز کو برقرار رکھنے کے لیے تیار ہوں۔ یہ ایک DAO ہو سکتا ہے جو تاریخی ڈیٹا اسٹوریج کو منظم کرنے کے لیے بنایا گیا ہو، یا مثالی طور پر یہ ان تمام آپشنز کا مجموعہ ہوگا۔ یہ فراہم کنندگان کئی طریقوں سے ڈیٹا پیش کر سکتے ہیں، جیسے کہ ٹورینٹ، FTP، Filecoin یا IPFS پر۔
ہسٹری کی میعاد ختم ہونا کسی حد تک متنازعہ ہے کیونکہ اب تک Ethereum نے ہمیشہ کسی بھی تاریخی ڈیٹا کی دستیابی کی واضح ضمانت دی ہے۔ جینیسس سے مکمل سنک ہمیشہ ایک معیار کے طور پر ممکن رہا ہے، یہاں تک کہ اگر یہ اسنیپ شاٹس سے کچھ پرانے ڈیٹا کو دوبارہ بنانے پر انحصار کرتا ہو۔ ہسٹری کی میعاد ختم ہونا اس ضمانت کو فراہم کرنے کی ذمہ داری کو Ethereum کے بنیادی پروٹوکول سے باہر منتقل کر دیتا ہے۔ اگر سینٹرلائزڈ تنظیمیں تاریخی ڈیٹا فراہم کرنے کے لیے آگے آتی ہیں تو اس سے سنسرشپ کے نئے خطرات پیدا ہو سکتے ہیں۔
EIP-4444 ابھی تک جاری (ship) ہونے کے لیے تیار نہیں ہے، لیکن اس پر فعال بحث جاری ہے۔ دلچسپ بات یہ ہے کہ EIP-4444 کے ساتھ چیلنجز اتنے تکنیکی نہیں ہیں، بلکہ زیادہ تر کمیونٹی مینجمنٹ کے ہیں۔ اسے جاری کرنے کے لیے، کمیونٹی کی رضامندی کی ضرورت ہے جس میں نہ صرف معاہدہ شامل ہو بلکہ قابل اعتماد اداروں کی جانب سے تاریخی ڈیٹا کو اسٹور کرنے اور فراہم کرنے کے وعدے بھی شامل ہوں۔
یہ اپ گریڈ بنیادی طور پر اس بات کو تبدیل نہیں کرتا کہ Ethereum نوڈز اسٹیٹ ڈیٹا کو کیسے ہینڈل کرتے ہیں، یہ صرف اس بات کو تبدیل کرتا ہے کہ تاریخی ڈیٹا تک کیسے رسائی حاصل کی جاتی ہے۔
اسٹیٹ کی میعاد ختم ہونا
اسٹیٹ کی میعاد ختم ہونے سے مراد انفرادی نوڈز سے اسٹیٹ کو ہٹانا ہے اگر حال ہی میں اس تک رسائی حاصل نہ کی گئی ہو۔ اسے نافذ کرنے کے کئی طریقے ہو سکتے ہیں، بشمول:
- کرائے کے ذریعے میعاد ختم ہونا (Expire by rent): اکاؤنٹس سے "کرایہ" وصول کرنا اور جب ان کا کرایہ صفر ہو جائے تو ان کی میعاد ختم کر دینا
- وقت کے ذریعے میعاد ختم ہونا (Expire by time): اگر کسی اکاؤنٹ میں کچھ عرصے تک کوئی ریڈنگ/رائٹنگ نہ ہو تو اسے غیر فعال کر دینا
کرائے کے ذریعے میعاد ختم ہونا اکاؤنٹس کو فعال اسٹیٹ ڈیٹا بیس میں رکھنے کے لیے ان سے براہ راست کرایہ وصول کرنا ہو سکتا ہے۔ وقت کے ذریعے میعاد ختم ہونا آخری اکاؤنٹ انٹریکشن سے الٹی گنتی کے ذریعے ہو سکتا ہے، یا یہ تمام اکاؤنٹس کی وقفے وقفے سے میعاد ختم ہونا ہو سکتا ہے۔ ایسے میکانزم بھی ہو سکتے ہیں جو وقت اور کرائے پر مبنی دونوں ماڈلز کے عناصر کو یکجا کرتے ہوں، مثال کے طور پر انفرادی اکاؤنٹس فعال اسٹیٹ میں برقرار رہتے ہیں اگر وہ وقت پر مبنی میعاد ختم ہونے سے پہلے کچھ چھوٹی فیس ادا کرتے ہیں۔ اسٹیٹ کی میعاد ختم ہونے کے ساتھ یہ نوٹ کرنا ضروری ہے کہ غیر فعال اسٹیٹ کو ڈیلیٹ نہیں کیا جاتا، اسے صرف فعال اسٹیٹ سے الگ اسٹور کیا جاتا ہے۔ غیر فعال اسٹیٹ کو دوبارہ فعال اسٹیٹ میں زندہ (resurrect) کیا جا سکتا ہے۔
یہ جس طرح کام کرے گا وہ شاید مخصوص ادوار (شاید ~1 سال) کے لیے ایک اسٹیٹ ٹری (state tree) کا ہونا ہے۔ جب بھی کوئی نیا دور شروع ہوتا ہے، تو ایک بالکل نیا اسٹیٹ ٹری بھی شروع ہوتا ہے۔ صرف موجودہ اسٹیٹ ٹری میں ترمیم کی جا سکتی ہے، باقی تمام ناقابل تغیر (immutable) ہوتے ہیں۔ Ethereum نوڈز سے صرف موجودہ اسٹیٹ ٹری اور اس سے پچھلے حالیہ ترین ٹری کو رکھنے کی توقع کی جاتی ہے۔ اس کے لیے کسی ایڈریس کو اس دور کے ساتھ ٹائم اسٹیمپ کرنے کے طریقے کی ضرورت ہوتی ہے جس میں وہ موجود ہے۔ ایسا کرنے کے کئی ممکنہ طریقے (opens in a new tab) ہیں، لیکن سب سے اہم آپشن کے لیے اضافی معلومات کو ایڈجسٹ کرنے کے لیے ایڈریسز کو طویل کرنے (opens in a new tab) کی ضرورت ہوتی ہے جس کا اضافی فائدہ یہ ہے کہ طویل ایڈریسز بہت زیادہ محفوظ ہوتے ہیں۔ روڈ میپ کا وہ آئٹم جو یہ کرتا ہے اسے ایڈریس اسپیس ایکسٹینشن (address space extension) (opens in a new tab) کہا جاتا ہے۔
ہسٹری کی میعاد ختم ہونے کی طرح، اسٹیٹ کی میعاد ختم ہونے کے تحت پرانے اسٹیٹ ڈیٹا کو اسٹور کرنے کی ذمہ داری انفرادی صارفین سے ہٹا دی جاتی ہے اور اسے دیگر اداروں جیسے سینٹرلائزڈ فراہم کنندگان، رضاکار کمیونٹی ممبران یا Portal Network جیسے مزید مستقبل کے ڈی سینٹرلائزڈ حلوں پر ڈال دیا جاتا ہے۔
اسٹیٹ کی میعاد ختم ہونا ابھی بھی تحقیق کے مرحلے میں ہے اور ابھی تک جاری ہونے کے لیے تیار نہیں ہے۔ اسٹیٹ کی میعاد ختم ہونا اسٹیٹ لیس کلائنٹس اور ہسٹری کی میعاد ختم ہونے کے بعد ہو سکتا ہے کیونکہ وہ اپ گریڈز اکثریت والے ویلیڈیٹرز کے لیے بڑے اسٹیٹ سائز کو آسانی سے قابل انتظام بناتے ہیں۔
اسٹیٹ لیسنیس
اسٹیٹ لیسنیس (Statelessness) کسی حد تک ایک غلط نام ہے کیونکہ اس کا مطلب یہ نہیں ہے کہ "اسٹیٹ" کا تصور ختم ہو گیا ہے، بلکہ اس میں یہ تبدیلیاں شامل ہیں کہ Ethereum نوڈز اسٹیٹ ڈیٹا کو کیسے ہینڈل کرتے ہیں۔ اسٹیٹ لیسنیس بذات خود دو اقسام میں آتی ہے: کمزور اسٹیٹ لیسنیس اور مضبوط اسٹیٹ لیسنیس۔ کمزور اسٹیٹ لیسنیس زیادہ تر نوڈز کو اسٹیٹ لیس ہونے کے قابل بناتی ہے اور اسٹیٹ اسٹوریج کی ذمہ داری چند نوڈز پر ڈال دیتی ہے۔ مضبوط اسٹیٹ لیسنیس کسی بھی نوڈ کے لیے مکمل اسٹیٹ ڈیٹا کو اسٹور کرنے کی ضرورت کو مکمل طور پر ختم کر دیتی ہے۔ کمزور اور مضبوط دونوں اسٹیٹ لیسنیس عام ویلیڈیٹرز کو درج ذیل فوائد پیش کرتی ہیں:
- تقریباً فوری سنکنگ
- بلاکس کو آؤٹ آف آرڈر (out-of-order) ویلیڈیٹ کرنے کی صلاحیت
- نوڈز بہت کم ہارڈویئر کی ضروریات کے ساتھ چلنے کے قابل (مثلاً، فونز پر)
- نوڈز سستی ہارڈ ڈرائیوز پر چل سکتے ہیں کیونکہ ڈسک ریڈنگ/رائٹنگ کی ضرورت نہیں ہوتی
- Ethereum کی کرپٹوگرافی میں مستقبل کے اپ گریڈز کے ساتھ ہم آہنگ
کمزور اسٹیٹ لیسنیس
کمزور اسٹیٹ لیسنیس میں ان طریقوں میں تبدیلیاں شامل ہیں جن سے Ethereum نوڈز اسٹیٹ کی تبدیلیوں کی تصدیق کرتے ہیں، لیکن یہ نیٹ ورک پر موجود تمام نوڈز میں اسٹیٹ اسٹوریج کی ضرورت کو مکمل طور پر ختم نہیں کرتی۔ اس کے بجائے، کمزور اسٹیٹ لیسنیس اسٹیٹ اسٹوریج کی ذمہ داری بلاک پروپوزرز پر ڈال دیتی ہے، جبکہ نیٹ ورک پر موجود دیگر تمام نوڈز مکمل اسٹیٹ ڈیٹا کو اسٹور کیے بغیر بلاکس کی تصدیق کرتے ہیں۔
کمزور اسٹیٹ لیسنیس میں بلاکس تجویز کرنے کے لیے مکمل اسٹیٹ ڈیٹا تک رسائی کی ضرورت ہوتی ہے لیکن بلاکس کی تصدیق کے لیے کسی اسٹیٹ ڈیٹا کی ضرورت نہیں ہوتی
ایسا ہونے کے لیے، Ethereum کلائنٹس میں Verkle trees کا پہلے سے نافذ ہونا ضروری ہے۔ Verkle trees، Ethereum کے اسٹیٹ ڈیٹا کو اسٹور کرنے کے لیے ایک متبادل ڈیٹا اسٹرکچر ہیں جو ڈیٹا کے چھوٹے، مقررہ سائز کے "گواہوں (witnesses)" کو پیئرز کے درمیان منتقل کرنے اور مقامی ڈیٹا بیس کے خلاف بلاکس کی تصدیق کرنے کے بجائے بلاکس کی تصدیق کے لیے استعمال کرنے کی اجازت دیتے ہیں۔ پروپوزر-بلڈر علیحدگی (Proposer-builder separation) کی بھی ضرورت ہے کیونکہ یہ بلاک بلڈرز کو زیادہ طاقتور ہارڈویئر کے ساتھ مخصوص نوڈز بننے کی اجازت دیتا ہے، اور یہی وہ نوڈز ہیں جنہیں مکمل اسٹیٹ ڈیٹا تک رسائی کی ضرورت ہوتی ہے۔
بلاک پروپوزرز اسٹیٹ ڈیٹا کا استعمال کرتے ہوئے "گواہ (witnesses)" بناتے ہیں - ڈیٹا کا وہ کم از کم سیٹ جو اسٹیٹ کی ان اقدار کو ثابت کرتا ہے جنہیں بلاک میں موجود ٹرانزیکشنز کے ذریعے تبدیل کیا جا رہا ہے۔ دیگر ویلیڈیٹرز اسٹیٹ کو نہیں رکھتے، وہ صرف اسٹیٹ روٹ (پوری اسٹیٹ کا ایک ہیش) اسٹور کرتے ہیں۔ وہ ایک بلاک اور ایک گواہ وصول کرتے ہیں اور انہیں اپنے اسٹیٹ روٹ کو اپ ڈیٹ کرنے کے لیے استعمال کرتے ہیں۔ یہ ایک ویلیڈیٹنگ نوڈ کو انتہائی ہلکا (lightweight) بنا دیتا ہے۔
کمزور اسٹیٹ لیسنیس تحقیق کے ایک اعلیٰ مرحلے میں ہے، لیکن اس کا انحصار پروپوزر-بلڈر علیحدگی اور Verkle Trees کے نافذ ہونے پر ہے تاکہ چھوٹے گواہوں کو پیئرز کے درمیان منتقل کیا جا سکے۔ اس کا مطلب ہے کہ کمزور اسٹیٹ لیسنیس شاید Ethereum مین نیٹ (Mainnet) سے چند سال دور ہے۔
L1 کی تصدیق کے لیے zkEVM ایک تکمیلی ٹیکنالوجی ہے جو سٹیٹ لیس (stateless) تصدیق کو مزید بہتر بنا سکتی ہے۔ صرف گواہوں (witnesses) کی جانچ کرنے کے بجائے، تصدیق کنندگان اس بات کے زیرو نالج ثبوت کی تصدیق کر سکتے ہیں کہ پورا بلاک درست طریقے سے عمل میں لایا گیا تھا -- جو ٹرانزیکشنز کو دوبارہ چلائے بغیر کرپٹوگرافک یقین فراہم کرتا ہے۔
مضبوط اسٹیٹ لیسنیس
مضبوط اسٹیٹ لیسنیس کسی بھی نوڈ کے لیے اسٹیٹ ڈیٹا کو اسٹور کرنے کی ضرورت کو ختم کر دیتی ہے۔ اس کے بجائے، ٹرانزیکشنز کو گواہوں کے ساتھ بھیجا جاتا ہے جنہیں بلاک پروڈیوسرز کے ذریعے جمع (aggregate) کیا جا سکتا ہے۔ پھر بلاک پروڈیوسرز صرف اس اسٹیٹ کو اسٹور کرنے کے ذمہ دار ہوتے ہیں جو متعلقہ اکاؤنٹس کے لیے گواہ تیار کرنے کے لیے درکار ہوتی ہے۔ اسٹیٹ کی ذمہ داری تقریباً مکمل طور پر صارفین پر منتقل کر دی جاتی ہے، کیونکہ وہ یہ اعلان کرنے کے لیے گواہ اور 'ایکسیس لسٹس (access lists)' بھیجتے ہیں کہ وہ کن اکاؤنٹس اور اسٹوریج کیز کے ساتھ تعامل کر رہے ہیں۔ یہ انتہائی ہلکے نوڈز کو فعال کرے گا، لیکن اس میں کچھ سمجھوتے (tradeoffs) شامل ہیں جن میں اسمارٹ کانٹریکٹس کے ساتھ ٹرانزیکشن کرنا زیادہ مشکل بنانا شامل ہے۔
محققین کی جانب سے مضبوط اسٹیٹ لیسنیس کی چھان بین کی گئی ہے لیکن فی الحال اس کے Ethereum کے روڈ میپ کا حصہ بننے کی توقع نہیں ہے - اس بات کا زیادہ امکان ہے کہ کمزور اسٹیٹ لیسنیس Ethereum کی اسکیلنگ کی ضروریات کے لیے کافی ہے۔
موجودہ پیش رفت
کمزور اسٹیٹ لیسنیس، ہسٹری کی میعاد ختم ہونا اور اسٹیٹ کی میعاد ختم ہونا سبھی تحقیق کے مرحلے میں ہیں اور توقع ہے کہ اب سے کئی سال بعد جاری ہوں گے۔ اس بات کی کوئی ضمانت نہیں ہے کہ یہ تمام تجاویز نافذ کی جائیں گی، مثال کے طور پر، اگر اسٹیٹ کی میعاد ختم ہونے کو پہلے نافذ کیا جاتا ہے تو شاید ہسٹری کی میعاد ختم ہونے کو بھی نافذ کرنے کی ضرورت نہ رہے۔ روڈ میپ کے دیگر آئٹمز بھی ہیں، جیسے کہ Verkle Trees اور پروپوزر-بلڈر علیحدگی (Proposer-builder separation) جنہیں پہلے مکمل کرنے کی ضرورت ہے۔
مزید مطالعہ
- اسٹیٹ لیس Ethereum کیا ہے؟ (opens in a new tab)
- Vitalik کا اسٹیٹ لیسنیس پر AMA (opens in a new tab)
- اسٹیٹ سائز مینجمنٹ کا ایک نظریہ (opens in a new tab)
- Resurrection-conflict-minimized state bounding (opens in a new tab)
- اسٹیٹ لیسنیس اور اسٹیٹ کی میعاد ختم ہونے کے راستے (opens in a new tab)
- EIP-4444 کی تفصیلات (opens in a new tab)
- EIP-4444 پر Alex Stokes (opens in a new tab)
- اسٹیٹ لیس ہونا اتنا اہم کیوں ہے (opens in a new tab)
- اصل اسٹیٹ لیس کلائنٹ کے تصور کے نوٹس (opens in a new tab)
- اسٹیٹ کی میعاد ختم ہونے پر مزید (opens in a new tab)
- اسٹیٹ کی میعاد ختم ہونے پر اور بھی مزید (opens in a new tab)
- اسٹیٹ لیس Ethereum کا معلوماتی صفحہ (opens in a new tab)
صفحہ کی آخری اپ ڈیٹ: 26 مارچ، 2026
