مرکل پیٹریشیا ٹرائی

Ethereum کی اسٹیٹ (تمام اکاؤنٹس، بیلنسز، اور اسمارٹ کانٹریکٹس کا مجموعہ)، ڈیٹا اسٹرکچر کے ایک خاص ورژن میں انکوڈ کی جاتی ہے جسے کمپیوٹر سائنس میں عام طور پر مرکل ٹری (Merkle Tree) کے نام سے جانا جاتا ہے۔ یہ اسٹرکچر کرپٹوگرافی میں بہت سی ایپلی کیشنز کے لیے مفید ہے کیونکہ یہ ٹری میں الجھے ہوئے ڈیٹا کے تمام انفرادی حصوں کے درمیان ایک قابل تصدیق تعلق پیدا کرتا ہے، جس کے نتیجے میں ایک واحد روٹ (root) ویلیو حاصل ہوتی ہے جسے ڈیٹا کے بارے میں چیزیں ثابت کرنے کے لیے استعمال کیا جا سکتا ہے۔

Ethereum کا ڈیٹا اسٹرکچر ایک 'ترمیم شدہ مرکل-پیٹریشیا ٹرائی (modified Merkle-Patricia Trie)' ہے، اس کا نام اس لیے رکھا گیا ہے کیونکہ یہ PATRICIA (the Practical Algorithm To Retrieve Information Coded in Alphanumeric) کی کچھ خصوصیات مستعار لیتا ہے، اور اس لیے کہ اسے ان آئٹمز کی موثر ڈیٹا بازیافت (retrieval) کے لیے ڈیزائن کیا گیا ہے جو Ethereum کی اسٹیٹ پر مشتمل ہیں۔

ایک مرکل-پیٹریشیا ٹرائی ڈیٹرمنسٹک (deterministic) اور کرپٹوگرافک طور پر قابل تصدیق ہے: اسٹیٹ روٹ بنانے کا واحد طریقہ اسے اسٹیٹ کے ہر انفرادی حصے سے کمپیوٹ کرنا ہے، اور دو اسٹیٹس جو ایک جیسی ہیں انہیں روٹ ہیش اور ان ہیشز کا موازنہ کر کے آسانی سے ثابت کیا جا سکتا ہے جو اس تک لے گئے (ایک مرکل پروف)۔ اس کے برعکس، ایک ہی روٹ ہیش کے ساتھ دو مختلف اسٹیٹس بنانے کا کوئی طریقہ نہیں ہے، اور مختلف ویلیوز کے ساتھ اسٹیٹ میں ترمیم کرنے کی کسی بھی کوشش کے نتیجے میں ایک مختلف اسٹیٹ روٹ ہیش ہوگا۔ نظریاتی طور پر، یہ اسٹرکچر انسرٹس، لک اپس اور ڈیلیٹس کے لیے O(log(n)) کارکردگی کا 'ہولی گریل (holy grail)' فراہم کرتا ہے۔

مستقبل قریب میں، Ethereum کا ایک ورکل ٹری (Verkle Tree) اسٹرکچر پر منتقل ہونے کا ارادہ ہے، جو مستقبل میں پروٹوکول کی بہتری کے لیے بہت سے نئے امکانات کھولے گا۔

پیشگی شرائط

اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہیشز (hashes) (opens in a new tab)، مرکل ٹریز (Merkle trees) (opens in a new tab)، ٹرائیز (tries) (opens in a new tab) اور سیریلائزیشن (serialization) (opens in a new tab) کا بنیادی علم ہونا مددگار ثابت ہوگا۔ یہ مضمون ایک بنیادی ریڈکس ٹری (radix tree) (opens in a new tab) کی تفصیل سے شروع ہوتا ہے، پھر بتدریج Ethereum کے زیادہ آپٹمائزڈ ڈیٹا اسٹرکچر کے لیے ضروری ترامیم متعارف کراتا ہے۔

بنیادی ریڈکس ٹرائیز

ایک بنیادی ریڈکس ٹرائی میں، ہر نوڈ اس طرح نظر آتا ہے:

1    [i_0, i_1 ... i_n, value]

جہاں i_0 ... i_n حروف تہجی کی علامتوں (اکثر بائنری یا ہیکس) کی نمائندگی کرتے ہیں، value نوڈ پر ٹرمینل ویلیو ہے، اور i_0, i_1 ... i_n سلاٹس میں ویلیوز یا تو NULL ہیں یا دوسرے نوڈز کے پوائنٹرز (ہمارے معاملے میں، ہیشز) ہیں۔ یہ ایک بنیادی (key, value) اسٹور بناتا ہے۔

فرض کریں کہ آپ کلیدی ویلیو پیئرز (key value pairs) کے سیٹ پر ایک آرڈر کو برقرار رکھنے کے لیے ریڈکس ٹری ڈیٹا اسٹرکچر استعمال کرنا چاہتے ہیں۔ ٹرائی میں کلید dog پر میپ کی گئی موجودہ ویلیو تلاش کرنے کے لیے، آپ پہلے dog کو حروف تہجی کے حروف میں تبدیل کریں گے (جس سے 64 6f 67 حاصل ہوگا)، اور پھر اس راستے پر چلتے ہوئے ٹرائی میں نیچے جائیں گے جب تک کہ آپ کو ویلیو نہ مل جائے۔ یعنی، آپ ٹرائی کا روٹ نوڈ تلاش کرنے کے لیے فلیٹ کلید/ویلیو DB میں روٹ ہیش کو تلاش کر کے شروع کرتے ہیں۔ اسے دوسرے نوڈز کی طرف اشارہ کرنے والی کلیدوں کی ایک سرنی (array) کے طور پر دکھایا گیا ہے۔ آپ انڈیکس 6 پر موجود ویلیو کو کلید کے طور پر استعمال کریں گے اور ایک لیول نیچے نوڈ حاصل کرنے کے لیے اسے فلیٹ کلید/ویلیو DB میں تلاش کریں گے۔ پھر اگلی ویلیو تلاش کرنے کے لیے انڈیکس 4 کا انتخاب کریں، پھر انڈیکس 6 کا انتخاب کریں، اور اسی طرح، یہاں تک کہ، ایک بار جب آپ نے راستے کی پیروی کی: root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7، آپ نوڈ کی ویلیو تلاش کریں گے اور نتیجہ واپس کریں گے۔

'ٹرائی' اور بنیادی فلیٹ کلید/ویلیو 'DB' میں کچھ تلاش کرنے کے درمیان فرق ہے۔ وہ دونوں کلید/ویلیو کے انتظامات کی وضاحت کرتے ہیں، لیکن بنیادی DB کلید کا روایتی 1 قدمی لک اپ کر سکتا ہے۔ ٹرائی میں کلید تلاش کرنے کے لیے اوپر بیان کردہ حتمی ویلیو تک پہنچنے کے لیے متعدد بنیادی DB لک اپس کی ضرورت ہوتی ہے۔ ابہام کو دور کرنے کے لیے آئیے مؤخر الذکر کو path کے طور پر حوالہ دیں۔

ریڈکس ٹرائیز کے لیے اپ ڈیٹ اور ڈیلیٹ آپریشنز کی وضاحت اس طرح کی جا سکتی ہے:

1    def update(node_hash, path, value):
2        curnode = db.get(node_hash) if node_hash else [NULL] * 17
3        newnode = curnode.copy()
4        if path == "":
5            newnode[-1] = value
6        else:
7            newindex = update(curnode[path[0]], path[1:], value)
8            newnode[path[0]] = newindex
9        db.put(hash(newnode), newnode)
10        return hash(newnode)
11
12    def delete(node_hash, path):
13        if node_hash is NULL:
14            return NULL
15        else:
16            curnode = db.get(node_hash)
17            newnode = curnode.copy()
18            if path == "":
19                newnode[-1] = NULL
20            else:
21                newindex = delete(curnode[path[0]], path[1:])
22                newnode[path[0]] = newindex
23
24            if all(x is NULL for x in newnode):
25                return NULL
26            else:
27                db.put(hash(newnode), newnode)
28                return hash(newnode)
سب دکھائیں

ایک "مرکل" ریڈکس ٹری ڈیٹرمنسٹک طور پر تیار کردہ کرپٹوگرافک ہیش ڈائجسٹس کا استعمال کرتے ہوئے نوڈس کو جوڑ کر بنایا گیا ہے۔ یہ مواد کی ایڈریسنگ (کلید/ویلیو DB میں key == keccak256(rlp(value))) ذخیرہ شدہ ڈیٹا کی کرپٹوگرافک سالمیت کی ضمانت فراہم کرتی ہے۔ اگر کسی دیے گئے ٹرائی کا روٹ ہیش عوامی طور پر جانا جاتا ہے، تو بنیادی لیف ڈیٹا تک رسائی رکھنے والا کوئی بھی شخص یہ ثبوت بنا سکتا ہے کہ ٹرائی میں ایک مخصوص راستے پر دی گئی ویلیو شامل ہے، ہر نوڈ کے ہیشز فراہم کر کے جو ایک مخصوص ویلیو کو ٹری کے روٹ سے جوڑتے ہیں۔

حملہ آور کے لیے ایسے (path, value) پیئر کا ثبوت فراہم کرنا ناممکن ہے جو موجود نہیں ہے کیونکہ روٹ ہیش بالآخر اس کے نیچے موجود تمام ہیشز پر مبنی ہوتا ہے۔ کوئی بھی بنیادی ترمیم روٹ ہیش کو بدل دے گی۔ آپ ہیش کو ڈیٹا کے بارے میں ساختی معلومات کی کمپریسڈ نمائندگی کے طور پر سوچ سکتے ہیں، جو ہیشنگ فنکشن کے پری-امیج پروٹیکشن کے ذریعے محفوظ ہے۔

ہم ریڈکس ٹری کی ایٹمی اکائی (مثلاً، ایک ہیکس کریکٹر، یا 4 بٹ بائنری نمبر) کو "نبل (nibble)" کہیں گے۔ ایک وقت میں ایک نبل کا راستہ عبور کرتے ہوئے، جیسا کہ اوپر بیان کیا گیا ہے، نوڈس زیادہ سے زیادہ 16 چلڈرن کا حوالہ دے سکتے ہیں لیکن ان میں ایک value عنصر شامل ہوتا ہے۔ لہذا، ہم انہیں 17 کی لمبائی والی سرنی (array) کے طور پر پیش کرتے ہیں۔ ہم ان 17 عنصری سرنیوں کو "برانچ نوڈس (branch nodes)" کہتے ہیں۔

مرکل پیٹریشیا ٹرائی

ریڈکس ٹرائیز کی ایک بڑی حد ہے: وہ غیر موثر ہیں۔ اگر آپ ایک (path, value) بائنڈنگ کو اسٹور کرنا چاہتے ہیں جہاں راستہ، جیسا کہ Ethereum میں، 64 حروف طویل ہے (bytes32 میں نبلز کی تعداد)، تو ہمیں فی کریکٹر ایک لیول اسٹور کرنے کے لیے ایک کلو بائٹ سے زیادہ اضافی جگہ کی ضرورت ہوگی، اور ہر لک اپ یا ڈیلیٹ میں پورے 64 مراحل لگیں گے۔ ذیل میں متعارف کرایا گیا پیٹریشیا ٹرائی اس مسئلے کو حل کرتا ہے۔

آپٹمائزیشن

مرکل پیٹریشیا ٹرائی میں ایک نوڈ درج ذیل میں سے ایک ہے:

NULL (خالی اسٹرنگ کے طور پر دکھایا گیا ہے)
branch ایک 17-آئٹم نوڈ [ v0 ... v15, vt ]
leaf ایک 2-آئٹم نوڈ [ encodedPath, value ]
extension ایک 2-آئٹم نوڈ [ encodedPath, key ]

64 کریکٹر پاتھس کے ساتھ یہ ناگزیر ہے کہ ٹرائی کی پہلی چند تہوں کو عبور کرنے کے بعد، آپ ایک ایسے نوڈ پر پہنچ جائیں گے جہاں کم از کم راستے کے کچھ حصے کے لیے کوئی مختلف راستہ موجود نہیں ہے۔ راستے میں 15 تک اسپارس NULL نوڈس بنانے سے بچنے کے لیے، ہم [ encodedPath, key ] کی شکل کا ایک extension نوڈ ترتیب دے کر نزول کو شارٹ کٹ کرتے ہیں، جہاں encodedPath میں آگے بڑھنے کے لیے "جزوی راستہ (partial path)" شامل ہوتا ہے (نیچے بیان کردہ کمپیکٹ انکوڈنگ کا استعمال کرتے ہوئے)، اور key اگلے DB لک اپ کے لیے ہے۔

ایک leaf نوڈ کے لیے، جسے encodedPath کے پہلے نبل میں ایک فلیگ کے ذریعے نشان زد کیا جا سکتا ہے، راستہ تمام پچھلے نوڈ کے راستے کے ٹکڑوں کو انکوڈ کرتا ہے اور ہم براہ راست value تلاش کر سکتے ہیں۔

تاہم، یہ مندرجہ بالا آپٹمائزیشن ابہام پیدا کرتی ہے۔

نبلز میں راستوں کو عبور کرتے وقت، ہمارے پاس عبور کرنے کے لیے نبلز کی طاق (odd) تعداد ہو سکتی ہے، لیکن چونکہ تمام ڈیٹا bytes فارمیٹ میں محفوظ ہوتا ہے۔ مثال کے طور پر، نبل 1، اور نبلز 01 کے درمیان فرق کرنا ممکن نہیں ہے (دونوں کو <01> کے طور پر محفوظ کیا جانا چاہیے)۔ طاق لمبائی کی وضاحت کرنے کے لیے، جزوی راستے کے شروع میں ایک فلیگ لگایا جاتا ہے۔

تفصیلات: اختیاری ٹرمینیٹر کے ساتھ ہیکس ترتیب کی کمپیکٹ انکوڈنگ

جیسا کہ اوپر بیان کیا گیا ہے طاق بمقابلہ جفت باقی جزوی راستے کی لمبائی اور لیف بمقابلہ ایکسٹینشن نوڈ دونوں کی فلیگنگ کسی بھی 2-آئٹم نوڈ کے جزوی راستے کے پہلے نبل میں رہتی ہے۔ ان کے نتیجے میں درج ذیل حاصل ہوتا ہے:

ہیکس کریکٹر	بٹس	نوڈ کی قسم جزوی	راستے کی لمبائی
0	0000	extension	جفت (even)
1	0001	extension	طاق (odd)
2	0010	terminating (leaf)	جفت (even)
3	0011	terminating (leaf)	طاق (odd)

جفت باقی راستے کی لمبائی (0 یا 2) کے لیے، ایک اور 0 "پیڈنگ (padding)" نبل ہمیشہ پیروی کرے گا۔

1    def compact_encode(hexarray):
2        term = 1 if hexarray[-1] == 16 else 0
3        if term:
4            hexarray = hexarray[:-1]
5        oddlen = len(hexarray) % 2
6        flags = 2 * term + oddlen
7        if oddlen:
8            hexarray = [flags] + hexarray
9        else:
10            hexarray = [flags] + [0] + hexarray
11        # hexarray کی لمبائی اب جفت ہے، جس کا پہلا نبل فلیگز ہے۔
12        o = ""
13        for i in range(0, len(hexarray), 2):
14            o += chr(16 * hexarray[i] + hexarray[i + 1])
15        return o
سب دکھائیں

مثالیں:

1    > [1, 2, 3, 4, 5, ...]
2    '11 23 45'
3    > [0, 1, 2, 3, 4, 5, ...]
4    '00 01 23 45'
5    > [0, f, 1, c, b, 8, 10]
6    '20 0f 1c b8'
7    > [f, 1, c, b, 8, 10]
8    '3f 1c b8'

مرکل پیٹریشیا ٹرائی میں نوڈ حاصل کرنے کے لیے توسیعی کوڈ یہ ہے:

1    def get_helper(node_hash, path):
2        if path == []:
3            return node_hash
4        if node_hash == "":
5            return ""
6        curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash))
7        if len(curnode) == 2:
8            (k2, v2) = curnode
9            k2 = compact_decode(k2)
10            if k2 == path[: len(k2)]:
11                return get(v2, path[len(k2) :])
12            else:
13                return ""
14        elif len(curnode) == 17:
15            return get_helper(curnode[path[0]], path[1:])
16
17    def get(node_hash, path):
18        path2 = []
19        for i in range(len(path)):
20            path2.push(int(ord(path[i]) / 16))
21            path2.push(ord(path[i]) % 16)
22        path2.push(16)
23        return get_helper(node_hash, path2)
سب دکھائیں

مثال ٹرائی

فرض کریں کہ ہم ایک ٹرائی چاہتے ہیں جس میں چار پاتھ/ویلیو پیئرز ('do', 'verb')، ('dog', 'puppy')، ('doge', 'coins')، ('horse', 'stallion') شامل ہوں۔

سب سے پہلے، ہم راستوں اور ویلیوز دونوں کو bytes میں تبدیل کرتے ہیں۔ ذیل میں، راستوں کے لیے اصل بائٹ کی نمائندگی کو <> سے ظاہر کیا گیا ہے، حالانکہ ویلیوز کو اب بھی اسٹرنگز کے طور پر دکھایا گیا ہے، جنہیں آسانی سے سمجھنے کے لیے '' سے ظاہر کیا گیا ہے (وہ بھی دراصل bytes ہوں گے):

1    <64 6f> : 'verb'
2    <64 6f 67> : 'puppy'
3    <64 6f 67 65> : 'coins'
4    <68 6f 72 73 65> : 'stallion'

اب، ہم بنیادی DB میں درج ذیل کلید/ویلیو پیئرز کے ساتھ ایسا ٹرائی بناتے ہیں:

1    rootHash: [ <16>, hashA ]
2    hashA:    [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ]
3    hashB:    [ <00 6f>, hashC ]
4    hashC:    [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ]
5    hashD:    [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ]

جب ایک نوڈ کا حوالہ دوسرے نوڈ کے اندر دیا جاتا ہے، تو اس میں keccak256(rlp.encode(node)) شامل ہوتا ہے، اگر len(rlp.encode(node)) >= 32 بصورت دیگر node جہاں rlp.encode RLP انکوڈنگ فنکشن ہے۔

نوٹ کریں کہ ٹرائی کو اپ ڈیٹ کرتے وقت، کسی کو کلید/ویلیو پیئر (keccak256(x), x) کو ایک مستقل لک اپ ٹیبل میں اسٹور کرنے کی ضرورت ہوتی ہے اگر نئے بنائے گئے نوڈ کی لمبائی = 32 ہو۔ تاہم، اگر نوڈ اس سے چھوٹا ہے، تو کسی کو کچھ بھی اسٹور کرنے کی ضرورت نہیں ہے، کیونکہ فنکشن f(x) = x ریورسیبل (reversible) ہے۔

Ethereum میں ٹرائیز

Ethereum کی ایگزیکیوشن لیئر میں تمام مرکل ٹرائیز ایک مرکل پیٹریشیا ٹرائی کا استعمال کرتے ہیں۔

بلاک ہیڈر سے ان 3 ٹرائیز میں سے 3 روٹس ہوتے ہیں۔

stateRoot
transactionsRoot
receiptsRoot

اسٹیٹ ٹرائی

ایک عالمی اسٹیٹ ٹرائی ہے، اور جب بھی کوئی کلائنٹ کسی بلاک پر کارروائی کرتا ہے تو اسے اپ ڈیٹ کیا جاتا ہے۔ اس میں، ایک path ہمیشہ ہوتا ہے: keccak256(ethereumAddress) اور ایک value ہمیشہ ہوتی ہے: rlp(ethereumAccount)۔ خاص طور پر ایک Ethereum account [nonce,balance,storageRoot,codeHash] کی 4 آئٹم سرنی ہے۔ اس مقام پر، یہ بات قابل غور ہے کہ یہ storageRoot ایک اور پیٹریشیا ٹرائی کا روٹ ہے:

اسٹوریج ٹرائی

اسٹوریج ٹرائی وہ جگہ ہے جہاں کانٹریکٹ کا تمام ڈیٹا رہتا ہے۔ ہر اکاؤنٹ کے لیے ایک الگ اسٹوریج ٹرائی ہے۔ کسی دیے گئے ایڈریس پر مخصوص اسٹوریج پوزیشنز پر ویلیوز بازیافت کرنے کے لیے اسٹوریج ایڈریس، اسٹوریج میں محفوظ کردہ ڈیٹا کی انٹیجر پوزیشن، اور بلاک ID درکار ہوتی ہے۔ پھر انہیں JSON-RPC API میں بیان کردہ eth_getStorageAt میں دلائل کے طور پر پاس کیا جا سکتا ہے، مثال کے طور پر، ایڈریس 0x295a70b2de5e3953354a6a8344e616ed314d7251 کے لیے اسٹوریج سلاٹ 0 میں ڈیٹا بازیافت کرنے کے لیے:

curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"}

اسٹوریج میں دیگر عناصر کو بازیافت کرنا قدرے زیادہ پیچیدہ ہے کیونکہ اسٹوریج ٹرائی میں پوزیشن کا پہلے حساب لگایا جانا چاہیے۔ پوزیشن کا حساب ایڈریس کے keccak256 ہیش اور اسٹوریج پوزیشن کے طور پر لگایا جاتا ہے، دونوں کو 32 بائٹس کی لمبائی تک صفر کے ساتھ لیفٹ-پیڈ (left-padded) کیا جاتا ہے۔ مثال کے طور پر، ایڈریس 0x391694e7e0b0cce554cb130d723a9d27458f9298 کے لیے اسٹوریج سلاٹ 1 میں ڈیٹا کی پوزیشن یہ ہے:

1keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"))

Geth کنسول میں، اس کا حساب اس طرح لگایا جا سکتا ہے:

1> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001"
2undefined
3> web3.sha3(key, {"encoding": "hex"})
4"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9"

لہذا path keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>) ہے۔ اسے اب پہلے کی طرح اسٹوریج ٹرائی سے ڈیٹا بازیافت کرنے کے لیے استعمال کیا جا سکتا ہے:

curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545
{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"}

نوٹ: Ethereum اکاؤنٹ کے لیے storageRoot پہلے سے طے شدہ طور پر خالی ہوتا ہے اگر یہ کانٹریکٹ اکاؤنٹ نہیں ہے۔

ٹرانزیکشنز ٹرائی

ہر بلاک کے لیے ایک الگ ٹرانزیکشنز ٹرائی ہے، جو دوبارہ (key, value) پیئرز کو اسٹور کرتا ہے۔ یہاں ایک راستہ ہے: rlp(transactionIndex) جو اس کلید کی نمائندگی کرتا ہے جو اس کے ذریعے متعین کردہ ویلیو سے مطابقت رکھتی ہے:

1if legacyTx:
2  value = rlp(tx)
3else:
4  value = TxType | encode(tx)

اس بارے میں مزید معلومات EIP 2718 (opens in a new tab) دستاویزات میں مل سکتی ہیں۔

رسیدوں کا ٹرائی

ہر بلاک کا اپنا رسیدوں کا ٹرائی (Receipts trie) ہوتا ہے۔ یہاں ایک path ہے: rlp(transactionIndex)۔ transactionIndex اس بلاک کے اندر اس کا انڈیکس ہے جس میں اسے شامل کیا گیا تھا۔ رسیدوں کا ٹرائی کبھی اپ ڈیٹ نہیں ہوتا ہے۔ ٹرانزیکشنز ٹرائی کی طرح، موجودہ اور پرانی (legacy) رسیدیں ہیں۔ رسیدوں کے ٹرائی میں کسی مخصوص رسید کو استفسار (query) کرنے کے لیے، اس کے بلاک میں ٹرانزیکشن کا انڈیکس، رسید کا پے لوڈ اور ٹرانزیکشن کی قسم درکار ہوتی ہے۔ واپس کی گئی رسید Receipt قسم کی ہو سکتی ہے جسے TransactionType اور ReceiptPayload کے کنکیٹینیشن (concatenation) کے طور پر بیان کیا گیا ہے یا یہ LegacyReceipt قسم کی ہو سکتی ہے جسے rlp([status, cumulativeGasUsed, logsBloom, logs]) کے طور پر بیان کیا گیا ہے۔

اس بارے میں مزید معلومات EIP 2718 (opens in a new tab) دستاویزات میں مل سکتی ہیں۔

مرکل پیٹریشیا ٹرائی

پیشگی شرائط

بنیادی ریڈکس ٹرائیز

مرکل پیٹریشیا ٹرائی

آپٹمائزیشن

تفصیلات: اختیاری ٹرمینیٹر کے ساتھ ہیکس ترتیب کی کمپیکٹ انکوڈنگ

مثال ٹرائی

Ethereum میں ٹرائیز

اسٹیٹ ٹرائی

اسٹوریج ٹرائی

ٹرانزیکشنز ٹرائی

رسیدوں کا ٹرائی

مزید مطالعہ

کیا یہ مضمون مددگار تھا؟