---
title: "ورکل ٹریز"
description: "ورکل ٹریز کی ایک اعلیٰ سطحی تفصیل اور یہ کہ انہیں ایتھیریم کو اپ گریڈ کرنے کے لیے کیسے استعمال کیا جائے گا"
lang: ur
template: roadmap
summaryPoints:
  - دریافت کریں کہ ورکل ٹریز کیا ہیں
  - پڑھیں کہ ورکل ٹریز ایتھیریم کے لیے ایک مفید اپ گریڈ کیوں ہیں
---

ورکل ٹریز (<span dir="ltr">"Vector commitment"</span> اور <span dir="ltr">"Merkle Trees"</span> کا مجموعہ) ایک ایسا ڈیٹا سٹرکچر ہے جسے [ایتھیریم](/) نوڈز کو اپ گریڈ کرنے کے لیے استعمال کیا جا سکتا ہے تاکہ وہ بلاکس کی توثیق کرنے کی صلاحیت کھوئے بغیر حالت کے ڈیٹا کی بڑی مقدار کو ذخیرہ کرنا بند کر سکیں۔

## غیر حالتی کیفیت {#statelessness}

ورکل ٹریز غیر حالتی ایتھیریم کلائنٹس کی جانب ایک اہم قدم ہیں۔ غیر حالتی کلائنٹس وہ ہوتے ہیں جنہیں آنے والے بلاکس کی توثیق کرنے کے لیے پوری حالت کی ڈیٹا بیس کو ذخیرہ کرنے کی ضرورت نہیں ہوتی۔ بلاکس کی تصدیق کے لیے ایتھیریم کی حالت کی اپنی مقامی کاپی استعمال کرنے کے بجائے، غیر حالتی کلائنٹس حالت کے ڈیٹا کے لیے ایک "گواہ" کا استعمال کرتے ہیں جو بلاک کے ساتھ آتا ہے۔ گواہ حالت کے ڈیٹا کے انفرادی حصوں کا ایک مجموعہ ہے جو ٹرانزیکشنز کے ایک مخصوص سیٹ کو انجام دینے کے لیے درکار ہوتے ہیں، اور ایک کرپٹوگرافک ثبوت ہے کہ گواہ واقعی مکمل ڈیٹا کا حصہ ہے۔ گواہ کو حالت کی ڈیٹا بیس کی _بجائے_ استعمال کیا جاتا ہے۔ اس کے کام کرنے کے لیے، گواہوں کا بہت چھوٹا ہونا ضروری ہے، تاکہ انہیں نیٹ ورک پر محفوظ طریقے سے نشر کیا جا سکے اور توثیق کار انہیں <span dir="ltr">12</span> سیکنڈ کے سلاٹ کے اندر پروسیس کر سکیں۔ موجودہ حالت کا ڈیٹا سٹرکچر موزوں نہیں ہے کیونکہ گواہ بہت بڑے ہوتے ہیں۔ ورکل ٹریز چھوٹے گواہوں کو فعال کر کے اس مسئلے کو حل کرتے ہیں، جس سے غیر حالتی کلائنٹس کی راہ میں حائل اہم رکاوٹوں میں سے ایک دور ہو جاتی ہے۔

<ExpandableCard title="ہمیں غیر حالتی کلائنٹس کیوں چاہئیں؟" eventCategory="/roadmap/verkle-trees" eventName="clicked why do we want stateless clients?">

ایتھیریم کلائنٹس فی الحال اپنی حالت کا ڈیٹا ذخیرہ کرنے کے لیے ایک ڈیٹا سٹرکچر استعمال کرتے ہیں جسے <span dir="ltr">Patricia Merkle Trie</span> کہا جاتا ہے۔ انفرادی اکاؤنٹس کے بارے میں معلومات ٹرائی پر پتوں (leaves) کے طور پر ذخیرہ کی جاتی ہیں اور پتوں کے جوڑوں کو بار بار ہیش کیا جاتا ہے یہاں تک کہ صرف ایک ہیش باقی رہ جائے۔ اس آخری ہیش کو "روٹ" (root) کہا جاتا ہے۔ بلاکس کی تصدیق کے لیے، ایتھیریم کلائنٹس ایک بلاک میں موجود تمام ٹرانزیکشنز کو انجام دیتے ہیں اور اپنی مقامی حالت کی ٹرائی کو اپ ڈیٹ کرتے ہیں۔ بلاک کو درست سمجھا جاتا ہے اگر مقامی ٹری کا روٹ بلاک تجویز کنندہ کی طرف سے فراہم کردہ روٹ سے مماثل ہو، کیونکہ بلاک تجویز کنندہ اور توثیق کرنے والے نوڈ کی طرف سے کی گئی کمپیوٹیشن میں کوئی بھی فرق روٹ ہیش کو بالکل مختلف کر دے گا۔ اس کے ساتھ مسئلہ یہ ہے کہ بلاک چین کی تصدیق کے لیے ہر کلائنٹ کو ہیڈ بلاک اور کئی تاریخی بلاکس کے لیے پوری حالت کی ٹرائی کو ذخیرہ کرنے کی ضرورت ہوتی ہے (Geth میں ڈیفالٹ ہیڈ کے پیچھے <span dir="ltr">128</span> بلاکس کے لیے حالت کا ڈیٹا رکھنا ہے)۔ اس کے لیے کلائنٹس کو ڈسک کی ایک بڑی جگہ تک رسائی کی ضرورت ہوتی ہے، جو سستے، کم طاقت والے ہارڈویئر پر مکمل نوڈز چلانے میں ایک رکاوٹ ہے۔ اس کا ایک حل یہ ہے کہ حالت کی ٹرائی کو ایک زیادہ موثر سٹرکچر (ورکل ٹری) میں اپ ڈیٹ کیا جائے جس کا خلاصہ ڈیٹا کے ایک چھوٹے "گواہ" کا استعمال کرتے ہوئے کیا جا سکتا ہے جسے مکمل حالت کے ڈیٹا کے بجائے شیئر کیا جا سکتا ہے۔ حالت کے ڈیٹا کو ورکل ٹری میں دوبارہ فارمیٹ کرنا غیر حالتی کلائنٹس کی طرف بڑھنے کے لیے ایک اہم قدم ہے۔

</ExpandableCard>

## گواہ کیا ہے اور ہمیں ان کی ضرورت کیوں ہے؟ {#what-is-a-witness}

بلاک کی تصدیق کرنے کا مطلب ہے بلاک میں موجود ٹرانزیکشنز کو دوبارہ انجام دینا، ایتھیریم کی حالت کی ٹرائی میں تبدیلیاں لاگو کرنا، اور نئے روٹ ہیش کا حساب لگانا۔ ایک تصدیق شدہ بلاک وہ ہوتا ہے جس کا شمار شدہ حالت کا روٹ ہیش وہی ہوتا ہے جو بلاک کے ساتھ فراہم کیا گیا ہو (کیونکہ اس کا مطلب ہے کہ بلاک تجویز کنندہ نے واقعی وہی کمپیوٹیشن کی ہے جو وہ کہتے ہیں)۔ آج کے ایتھیریم کلائنٹس میں، حالت کو اپ ڈیٹ کرنے کے لیے پوری حالت کی ٹرائی تک رسائی کی ضرورت ہوتی ہے، جو کہ ایک بڑا ڈیٹا سٹرکچر ہے جسے مقامی طور پر ذخیرہ کیا جانا چاہیے۔ ایک گواہ میں صرف حالت کے ڈیٹا کے وہ ٹکڑے ہوتے ہیں جو بلاک میں ٹرانزیکشنز کو انجام دینے کے لیے درکار ہوتے ہیں۔ پھر ایک توثیق کار صرف ان ٹکڑوں کا استعمال کر کے اس بات کی تصدیق کر سکتا ہے کہ بلاک تجویز کنندہ نے بلاک کی ٹرانزیکشنز کو انجام دیا ہے اور حالت کو درست طریقے سے اپ ڈیٹ کیا ہے۔ تاہم، اس کا مطلب یہ ہے کہ گواہ کو ایتھیریم نیٹ ورک پر پیئرز کے درمیان اتنی تیزی سے منتقل کرنے کی ضرورت ہے کہ ہر نوڈ اسے <span dir="ltr">12</span> سیکنڈ کے سلاٹ کے اندر محفوظ طریقے سے وصول اور پروسیس کر سکے۔ اگر گواہ بہت بڑا ہے، تو کچھ نوڈز کو اسے ڈاؤن لوڈ کرنے اور چین کے ساتھ چلنے میں بہت زیادہ وقت لگ سکتا ہے۔ یہ ایک مرکزیت پیدا کرنے والی قوت ہے کیونکہ اس کا مطلب ہے کہ صرف تیز انٹرنیٹ کنکشن والے نوڈز ہی بلاکس کی توثیق میں حصہ لے سکتے ہیں۔ ورکل ٹریز کے ساتھ آپ کی ہارڈ ڈرائیو پر حالت کو ذخیرہ کرنے کی کوئی ضرورت نہیں ہے؛ بلاک کی تصدیق کے لیے آپ کو جس چیز کی بھی ضرورت ہے وہ بلاک کے اندر ہی موجود ہوتی ہے۔ بدقسمتی سے، مرکل ٹریز سے جو گواہ تیار کیے جا سکتے ہیں وہ غیر حالتی کلائنٹس کو سپورٹ کرنے کے لیے بہت بڑے ہوتے ہیں۔

## ورکل ٹریز چھوٹے گواہوں کو کیوں فعال کرتے ہیں؟ {#why-do-verkle-trees-enable-smaller-witnesses}

مرکل ٹرائی کا سٹرکچر گواہ کے سائز کو بہت بڑا بنا دیتا ہے - اتنا بڑا کہ اسے <span dir="ltr">12</span> سیکنڈ کے سلاٹ کے اندر پیئرز کے درمیان محفوظ طریقے سے نشر نہیں کیا جا سکتا۔ اس کی وجہ یہ ہے کہ گواہ ایک ایسا راستہ ہے جو ڈیٹا کو، جو پتوں میں رکھا جاتا ہے، روٹ ہیش سے جوڑتا ہے۔ ڈیٹا کی تصدیق کے لیے نہ صرف ان تمام درمیانی ہیشز کا ہونا ضروری ہے جو ہر پتے کو روٹ سے جوڑتے ہیں، بلکہ تمام "بہن بھائی" (sibling) نوڈز کا ہونا بھی ضروری ہے۔ ثبوت میں ہر نوڈ کا ایک بہن بھائی ہوتا ہے جس کے ساتھ اسے ہیش کر کے ٹرائی میں اگلا ہیش بنایا جاتا ہے۔ یہ بہت زیادہ ڈیٹا ہے۔ ورکل ٹریز درخت کے پتوں اور اس کے روٹ کے درمیان فاصلے کو کم کر کے اور روٹ ہیش کی تصدیق کے لیے بہن بھائی نوڈز فراہم کرنے کی ضرورت کو ختم کر کے گواہ کے سائز کو کم کرتے ہیں۔ ہیش طرز کی ویکٹر کمٹمنٹ کے بجائے ایک طاقتور پولی نومیل کمٹمنٹ (polynomial commitment) اسکیم کا استعمال کر کے جگہ کی اور بھی زیادہ بچت حاصل کی جائے گی۔ پولی نومیل کمٹمنٹ گواہ کو ایک مقررہ سائز رکھنے کی اجازت دیتی ہے قطع نظر اس کے کہ یہ کتنے پتوں کو ثابت کرتا ہے۔

پولی نومیل کمٹمنٹ اسکیم کے تحت، گواہوں کے سائز قابل انتظام ہوتے ہیں جنہیں پیئر ٹو پیئر نیٹ ورک پر آسانی سے منتقل کیا جا سکتا ہے۔ یہ کلائنٹس کو کم سے کم ڈیٹا کے ساتھ ہر بلاک میں حالت کی تبدیلیوں کی تصدیق کرنے کی اجازت دیتا ہے۔

<ExpandableCard title="ورکل ٹریز گواہ کے سائز کو بالکل کتنا کم کر سکتے ہیں؟" eventCategory="/roadmap/verkle-trees" eventName="clicked exactly how much can Verkle trees reduce witness size?">

گواہ کا سائز اس میں شامل پتوں کی تعداد کے لحاظ سے مختلف ہوتا ہے۔ یہ فرض کرتے ہوئے کہ گواہ <span dir="ltr">1000</span> پتوں کا احاطہ کرتا ہے، مرکل ٹرائی کے لیے ایک گواہ تقریباً <span dir="ltr">3.5MB</span> کا ہوگا (ٹرائی کے <span dir="ltr">7</span> لیولز فرض کرتے ہوئے)۔ ورکل ٹری میں اسی ڈیٹا کے لیے ایک گواہ (درخت کے <span dir="ltr">4</span> لیولز فرض کرتے ہوئے) تقریباً <span dir="ltr">150 kB</span> کا ہوگا - **تقریباً <span dir="ltr">23x</span> چھوٹا**۔ گواہ کے سائز میں یہ کمی غیر حالتی کلائنٹ کے گواہوں کو قابل قبول حد تک چھوٹا ہونے دے گی۔ پولی نومیل گواہ <span dir="ltr">0.128 -1 kB</span> کے ہوتے ہیں جس کا انحصار اس بات پر ہے کہ کون سی مخصوص پولی نومیل کمٹمنٹ استعمال کی گئی ہے۔

</ExpandableCard>

## ورکل ٹری کا سٹرکچر کیا ہے؟ {#what-is-the-structure-of-a-verkle-tree}

ورکل ٹریز `(key,value)` کے جوڑے ہیں جہاں کیز (keys) <span dir="ltr">32-byte</span> کے عناصر ہیں جو ایک <span dir="ltr">31-byte</span> کے _اسٹیم_ (stem) اور ایک سنگل بائٹ _سفکس_ (suffix) پر مشتمل ہوتے ہیں۔ ان کیز کو _ایکسٹینشن_ (extension) نوڈز اور _انر_ (inner) نوڈز میں منظم کیا جاتا ہے۔ ایکسٹینشن نوڈز مختلف سفکسز کے ساتھ <span dir="ltr">256</span> چلڈرن (children) کے لیے ایک واحد اسٹیم کی نمائندگی کرتے ہیں۔ انر نوڈز کے بھی <span dir="ltr">256</span> چلڈرن ہوتے ہیں، لیکن وہ دیگر ایکسٹینشن نوڈز ہو سکتے ہیں۔ ورکل ٹری اور مرکل ٹری کے سٹرکچر کے درمیان بنیادی فرق یہ ہے کہ ورکل ٹری بہت زیادہ چپٹا (flatter) ہوتا ہے، جس کا مطلب ہے کہ ایک پتے کو روٹ سے جوڑنے والے درمیانی نوڈز کم ہوتے ہیں، اور اس لیے ثبوت تیار کرنے کے لیے کم ڈیٹا درکار ہوتا ہے۔

![Diagram of a Verkle tree data structure](./verkle.png)

[ورکل ٹریز کے سٹرکچر کے بارے میں مزید پڑھیں](https://blog.ethereum.org/2021/12/02/verkle-tree-structure)

## موجودہ پیش رفت {#current-progress}

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

[دیکھیں Guillaume Ballet کو Condrieu ورکل آزمائشی نیٹ ورک کی وضاحت کرتے ہوئے](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (نوٹ کریں کہ Condrieu آزمائشی نیٹ ورک ثبوتِ کار (PoW) تھا اور اب اس کی جگہ Verkle Gen Devnet 6 آزمائشی نیٹ ورک نے لے لی ہے)۔

## مزید مطالعہ {#further-reading}

- [غیر حالتی کیفیت کے لیے ورکل ٹریز](https://verkle.info/)
- [PEEPanEIP پر Dankrad Feist کی ورکل ٹریز کی وضاحت](https://www.youtube.com/watch?v=RGJOQHzg3UQ)
- [ہم باقی سب کے لیے ورکل ٹریز](https://web.archive.org/web/20250124132255/https://research.2077.xyz/verkle-trees)
- [ورکل ثبوت کی اناٹومی](https://ihagopian.com/posts/anatomy-of-a-verkle-proof)
- [ETHGlobal میں Guillaume Ballet کی ورکل ٹریز کی وضاحت](https://www.youtube.com/watch?v=f7bEtX3Z57o)
- [Devcon 6 میں Guillaume Ballet کی جانب سے "ورکل ٹریز ایتھیریم کو کیسے چست اور طاقتور بناتے ہیں"](https://www.youtube.com/watch?v=Q7rStTKwuYs)
- [ETHDenver 2020 سے غیر حالتی کلائنٹس پر Piper Merriam کی گفتگو](https://www.youtube.com/watch?v=0yiZJNciIJ4)
- [Zero Knowledge پوڈ کاسٹ پر Dankrad Feist کی ورکل ٹریز اور غیر حالتی کیفیت کی وضاحت](https://zeroknowledge.fm/podcast/202/)
- [ورکل ٹریز پر وٹالک بوٹرین کی گفتگو](https://vitalik.eth.limo/general/2021/06/18/verkle.html)
- [ورکل ٹریز پر Dankrad Feist کی گفتگو](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html)
- [ورکل ٹری EIP کی دستاویزات](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration)