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

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

ایتھیریم کا ڈیٹا اسٹرکچر ایک 'موڈیفائیڈ مرکل-پیٹریشیا ٹرائی' ہے، جسے یہ نام اس لیے دیا گیا ہے کیونکہ یہ PATRICIA (پریکٹیکل الگورتھم ٹو ریٹریو انفارمیشن کوڈڈ ان ایلفانیومرک) کی کچھ خصوصیات مستعار لیتا ہے، اور کیونکہ اسے ایتھیریم اسٹیٹ پر مشتمل آئٹمز کی موثر ڈیٹا ریٹریول کے لیے ڈیزائن کیا گیا ہے۔

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

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

شرائط

اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہیشز (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) کی تفصیل سے شروع ہوتا ہے، پھر آہستہ آہستہ ایتھیریم کے زیادہ آپٹمائزڈ ڈیٹا اسٹرکچر کے لیے ضروری ترمیمات کا تعارف کراتا ہے۔

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

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

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

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

فرض کریں کہ آپ کلیدی ویلیو پیئرز کے ایک سیٹ پر ایک آرڈر کو برقرار رکھنے کے لیے ریڈکس ٹری ڈیٹا اسٹرکچر کا استعمال کرنا چاہتے ہیں۔ ٹرائی میں کلید dog سے فی الحال میپ شدہ ویلیو تلاش کرنے کے لیے، آپ پہلے dog کو حروف تہجی کے حروف میں تبدیل کریں گے (جو 64 6f 67 دے گا)، اور پھر اس راستے پر چلتے ہوئے ٹرائی میں نیچے جائیں گے جب تک کہ آپ کو ویلیو نہ مل جائے۔ یعنی، آپ ٹرائی کے روٹ نوڈ کو تلاش کرنے کے لیے ایک فلیٹ کی/ویلیو DB میں روٹ ہیش کو دیکھ کر شروع کرتے ہیں۔ اسے دوسرے نوڈس کی طرف اشارہ کرنے والی کلیدوں کی ایک صف کے طور پر ظاہر کیا جاتا ہے۔ آپ انڈیکس 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 بٹ بائنری نمبر) کو "نبل" کہیں گے۔ جیسا کہ اوپر بیان کیا گیا ہے، ایک وقت میں ایک نبل کے راستے پر چلتے ہوئے، نوڈس زیادہ سے زیادہ 16 بچوں کا حوالہ دے سکتے ہیں لیکن ایک value عنصر شامل کرتے ہیں۔ لہذا، ہم انہیں 17 کی لمبائی والی ایک صف کے طور پر ظاہر کرتے ہیں۔ ہم ان 17-عناصر والی صفوں کو "برانچ نوڈس" کہتے ہیں۔

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

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

آپٹمائزیشن

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

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

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

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

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

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

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

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

ہیکس کریکٹر	بٹس	نوڈ کی قسم جزوی	پاتھ کی لمبائی
0	0000	ایکسٹینشن	جفت
1	0001	ایکسٹینشن	طاق
2	0010	ٹرمینیٹنگ (لیف)	جفت
3	0011	ٹرمینیٹنگ (لیف)	طاق

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

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 قابلِ واپسی ہے۔

ایتھیریم میں ٹرائیز

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

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

stateRoot
transactionsRoot
receiptsRoot

اسٹیٹ ٹرائی

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

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

اسٹوریج ٹرائی وہ جگہ ہے جہاں تمام کنٹریکٹ ڈیٹا رہتا ہے۔ ہر اکاؤنٹ کے لیے ایک الگ اسٹوریج ٹرائی ہوتی ہے۔ کسی دیے گئے ایڈریس پر مخصوص اسٹوریج پوزیشنز پر ویلیوز کو بازیافت کرنے کے لیے اسٹوریج ایڈریس، اسٹوریج میں ذخیرہ شدہ ڈیٹا کی انٹیجر پوزیشن، اور بلاک آئی ڈی کی ضرورت ہوتی ہے۔ اس کے بعد انہیں 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 بائٹس کی لمبائی تک صفر کے ساتھ بائیں طرف پیڈ کیا جاتا ہے۔ مثال کے طور پر، ایڈریس 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"}

نوٹ: ایتھیریم اکاؤنٹ کے لیے storageRoot پہلے سے خالی ہوتا ہے اگر یہ کوئی کنٹریکٹ اکاؤنٹ نہ ہو۔

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

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

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

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

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

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

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

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

شرائط

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

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

آپٹمائزیشن

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

مثالی ٹرائی

ایتھیریم میں ٹرائیز

اسٹیٹ ٹرائی

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

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

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

مزید مطالعہ

کیا یہ آرٹیکل کارآمد تھا؟