ورکل ٹریز ("Vector commitment" اور "Merkle Trees" کا مجموعہ) ایک ایسا ڈیٹا سٹرکچر ہے جسے ایتھیریم نوڈز کو اپ گریڈ کرنے کے لیے استعمال کیا جا سکتا ہے تاکہ وہ بلاکس کی توثیق کرنے کی صلاحیت کھوئے بغیر حالت کے ڈیٹا کی بڑی مقدار کو ذخیرہ کرنا بند کر سکیں۔
غیر حالتی کیفیت
ورکل ٹریز غیر حالتی ایتھیریم کلائنٹس کی جانب ایک اہم قدم ہیں۔ غیر حالتی کلائنٹس وہ ہوتے ہیں جنہیں آنے والے بلاکس کی توثیق کرنے کے لیے پوری حالت کی ڈیٹا بیس کو ذخیرہ کرنے کی ضرورت نہیں ہوتی۔ بلاکس کی تصدیق کے لیے ایتھیریم کی حالت کی اپنی مقامی کاپی استعمال کرنے کے بجائے، غیر حالتی کلائنٹس حالت کے ڈیٹا کے لیے ایک "گواہ" کا استعمال کرتے ہیں جو بلاک کے ساتھ آتا ہے۔ گواہ حالت کے ڈیٹا کے انفرادی حصوں کا ایک مجموعہ ہے جو ٹرانزیکشنز کے ایک مخصوص سیٹ کو انجام دینے کے لیے درکار ہوتے ہیں، اور ایک کرپٹوگرافک ثبوت ہے کہ گواہ واقعی مکمل ڈیٹا کا حصہ ہے۔ گواہ کو حالت کی ڈیٹا بیس کی بجائے استعمال کیا جاتا ہے۔ اس کے کام کرنے کے لیے، گواہوں کا بہت چھوٹا ہونا ضروری ہے، تاکہ انہیں نیٹ ورک پر محفوظ طریقے سے نشر کیا جا سکے اور توثیق کار انہیں 12 سیکنڈ کے سلاٹ کے اندر پروسیس کر سکیں۔ موجودہ حالت کا ڈیٹا سٹرکچر موزوں نہیں ہے کیونکہ گواہ بہت بڑے ہوتے ہیں۔ ورکل ٹریز چھوٹے گواہوں کو فعال کر کے اس مسئلے کو حل کرتے ہیں، جس سے غیر حالتی کلائنٹس کی راہ میں حائل اہم رکاوٹوں میں سے ایک دور ہو جاتی ہے۔
گواہ کیا ہے اور ہمیں ان کی ضرورت کیوں ہے؟
بلاک کی تصدیق کرنے کا مطلب ہے بلاک میں موجود ٹرانزیکشنز کو دوبارہ انجام دینا، ایتھیریم کی حالت کی ٹرائی میں تبدیلیاں لاگو کرنا، اور نئے روٹ ہیش کا حساب لگانا۔ ایک تصدیق شدہ بلاک وہ ہوتا ہے جس کا شمار شدہ حالت کا روٹ ہیش وہی ہوتا ہے جو بلاک کے ساتھ فراہم کیا گیا ہو (کیونکہ اس کا مطلب ہے کہ بلاک تجویز کنندہ نے واقعی وہی کمپیوٹیشن کی ہے جو وہ کہتے ہیں)۔ آج کے ایتھیریم کلائنٹس میں، حالت کو اپ ڈیٹ کرنے کے لیے پوری حالت کی ٹرائی تک رسائی کی ضرورت ہوتی ہے، جو کہ ایک بڑا ڈیٹا سٹرکچر ہے جسے مقامی طور پر ذخیرہ کیا جانا چاہیے۔ ایک گواہ میں صرف حالت کے ڈیٹا کے وہ ٹکڑے ہوتے ہیں جو بلاک میں ٹرانزیکشنز کو انجام دینے کے لیے درکار ہوتے ہیں۔ پھر ایک توثیق کار صرف ان ٹکڑوں کا استعمال کر کے اس بات کی تصدیق کر سکتا ہے کہ بلاک تجویز کنندہ نے بلاک کی ٹرانزیکشنز کو انجام دیا ہے اور حالت کو درست طریقے سے اپ ڈیٹ کیا ہے۔ تاہم، اس کا مطلب یہ ہے کہ گواہ کو ایتھیریم نیٹ ورک پر پیئرز کے درمیان اتنی تیزی سے منتقل کرنے کی ضرورت ہے کہ ہر نوڈ اسے 12 سیکنڈ کے سلاٹ کے اندر محفوظ طریقے سے وصول اور پروسیس کر سکے۔ اگر گواہ بہت بڑا ہے، تو کچھ نوڈز کو اسے ڈاؤن لوڈ کرنے اور چین کے ساتھ چلنے میں بہت زیادہ وقت لگ سکتا ہے۔ یہ ایک مرکزیت پیدا کرنے والی قوت ہے کیونکہ اس کا مطلب ہے کہ صرف تیز انٹرنیٹ کنکشن والے نوڈز ہی بلاکس کی توثیق میں حصہ لے سکتے ہیں۔ ورکل ٹریز کے ساتھ آپ کی ہارڈ ڈرائیو پر حالت کو ذخیرہ کرنے کی کوئی ضرورت نہیں ہے؛ بلاک کی تصدیق کے لیے آپ کو جس چیز کی بھی ضرورت ہے وہ بلاک کے اندر ہی موجود ہوتی ہے۔ بدقسمتی سے، مرکل ٹریز سے جو گواہ تیار کیے جا سکتے ہیں وہ غیر حالتی کلائنٹس کو سپورٹ کرنے کے لیے بہت بڑے ہوتے ہیں۔
ورکل ٹریز چھوٹے گواہوں کو کیوں فعال کرتے ہیں؟
مرکل ٹرائی کا سٹرکچر گواہ کے سائز کو بہت بڑا بنا دیتا ہے - اتنا بڑا کہ اسے 12 سیکنڈ کے سلاٹ کے اندر پیئرز کے درمیان محفوظ طریقے سے نشر نہیں کیا جا سکتا۔ اس کی وجہ یہ ہے کہ گواہ ایک ایسا راستہ ہے جو ڈیٹا کو، جو پتوں میں رکھا جاتا ہے، روٹ ہیش سے جوڑتا ہے۔ ڈیٹا کی تصدیق کے لیے نہ صرف ان تمام درمیانی ہیشز کا ہونا ضروری ہے جو ہر پتے کو روٹ سے جوڑتے ہیں، بلکہ تمام "بہن بھائی" (sibling) نوڈز کا ہونا بھی ضروری ہے۔ ثبوت میں ہر نوڈ کا ایک بہن بھائی ہوتا ہے جس کے ساتھ اسے ہیش کر کے ٹرائی میں اگلا ہیش بنایا جاتا ہے۔ یہ بہت زیادہ ڈیٹا ہے۔ ورکل ٹریز درخت کے پتوں اور اس کے روٹ کے درمیان فاصلے کو کم کر کے اور روٹ ہیش کی تصدیق کے لیے بہن بھائی نوڈز فراہم کرنے کی ضرورت کو ختم کر کے گواہ کے سائز کو کم کرتے ہیں۔ ہیش طرز کی ویکٹر کمٹمنٹ کے بجائے ایک طاقتور پولی نومیل کمٹمنٹ (polynomial commitment) اسکیم کا استعمال کر کے جگہ کی اور بھی زیادہ بچت حاصل کی جائے گی۔ پولی نومیل کمٹمنٹ گواہ کو ایک مقررہ سائز رکھنے کی اجازت دیتی ہے قطع نظر اس کے کہ یہ کتنے پتوں کو ثابت کرتا ہے۔
پولی نومیل کمٹمنٹ اسکیم کے تحت، گواہوں کے سائز قابل انتظام ہوتے ہیں جنہیں پیئر ٹو پیئر نیٹ ورک پر آسانی سے منتقل کیا جا سکتا ہے۔ یہ کلائنٹس کو کم سے کم ڈیٹا کے ساتھ ہر بلاک میں حالت کی تبدیلیوں کی تصدیق کرنے کی اجازت دیتا ہے۔
ورکل ٹری کا سٹرکچر کیا ہے؟
ورکل ٹریز (key,value) کے جوڑے ہیں جہاں کیز (keys) 32-byte کے عناصر ہیں جو ایک 31-byte کے اسٹیم (stem) اور ایک سنگل بائٹ سفکس (suffix) پر مشتمل ہوتے ہیں۔ ان کیز کو ایکسٹینشن (extension) نوڈز اور انر (inner) نوڈز میں منظم کیا جاتا ہے۔ ایکسٹینشن نوڈز مختلف سفکسز کے ساتھ 256 چلڈرن (children) کے لیے ایک واحد اسٹیم کی نمائندگی کرتے ہیں۔ انر نوڈز کے بھی 256 چلڈرن ہوتے ہیں، لیکن وہ دیگر ایکسٹینشن نوڈز ہو سکتے ہیں۔ ورکل ٹری اور مرکل ٹری کے سٹرکچر کے درمیان بنیادی فرق یہ ہے کہ ورکل ٹری بہت زیادہ چپٹا (flatter) ہوتا ہے، جس کا مطلب ہے کہ ایک پتے کو روٹ سے جوڑنے والے درمیانی نوڈز کم ہوتے ہیں، اور اس لیے ثبوت تیار کرنے کے لیے کم ڈیٹا درکار ہوتا ہے۔
ورکل ٹریز کے سٹرکچر کے بارے میں مزید پڑھیں (opens in a new tab)
موجودہ پیش رفت
ورکل ٹری کے آزمائشی نیٹ ورکس پہلے ہی چل رہے ہیں، لیکن کلائنٹس میں ابھی بھی کافی اہم اپ ڈیٹس باقی ہیں جو ورکل ٹریز کو سپورٹ کرنے کے لیے درکار ہیں۔ آپ آزمائشی نیٹ ورکس پر کنٹریکٹس کو ڈیپلائے کر کے یا ٹیسٹ نیٹ کلائنٹس چلا کر پیش رفت کو تیز کرنے میں مدد کر سکتے ہیں۔
دیکھیں Guillaume Ballet کو Condrieu ورکل آزمائشی نیٹ ورک کی وضاحت کرتے ہوئے (opens in a new tab) (نوٹ کریں کہ Condrieu آزمائشی نیٹ ورک ثبوتِ کار (PoW) تھا اور اب اس کی جگہ Verkle Gen Devnet 6 آزمائشی نیٹ ورک نے لے لی ہے)۔
مزید مطالعہ
- غیر حالتی کیفیت کے لیے ورکل ٹریز (opens in a new tab)
- PEEPanEIP پر Dankrad Feist کی ورکل ٹریز کی وضاحت (opens in a new tab)
- ہم باقی سب کے لیے ورکل ٹریز (opens in a new tab)
- ورکل ثبوت کی اناٹومی (opens in a new tab)
- ETHGlobal میں Guillaume Ballet کی ورکل ٹریز کی وضاحت (opens in a new tab)
- Devcon 6 میں Guillaume Ballet کی جانب سے "ورکل ٹریز ایتھیریم کو کیسے چست اور طاقتور بناتے ہیں" (opens in a new tab)
- ETHDenver 2020 سے غیر حالتی کلائنٹس پر Piper Merriam کی گفتگو (opens in a new tab)
- Zero Knowledge پوڈ کاسٹ پر Dankrad Feist کی ورکل ٹریز اور غیر حالتی کیفیت کی وضاحت (opens in a new tab)
- ورکل ٹریز پر وٹالک بوٹرین کی گفتگو (opens in a new tab)
- ورکل ٹریز پر Dankrad Feist کی گفتگو (opens in a new tab)
- ورکل ٹری EIP کی دستاویزات (opens in a new tab)
صفحہ کی آخری اپ ڈیٹ: ۶ جون، ۲۰۲۶
