نوٹس اور کمٹمنٹ ٹری

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

ایک نوٹ

نوٹ { pk, from, amount, asset, time, r } ہے: 32 بٹ کے 28 ورڈز، 112 بائٹس، اس ترتیب میں: pk(8) from(8) amount_lo amount_hi asset time r(8)۔ pk مالک کی نوٹ پبلک ویلیو ہے (مشاہداتی کلید سے اخذ شدہ)، from بھیجنے والے کی، amount اکائیوں میں ایک u64 ہے (1 RAND = 10⁹ اکائیاں)، asset ایک u32 ہے (RAND کے لیے 0، ورنہ کسی RPL ٹوکن کے لیے، خواہ وہ برج شدہ ہو یا مقامی، ٹوکن رجسٹری کا متصل اشاریہ؛ دیکھیں RPL ٹوکن)، time وہ بلاک اونچائی ہے جسے بھیجنے والے نے ہدف بنایا، اور r اخفا کے آٹھ بے ترتیب ورڈز ہیں۔

سادہ متن چین پر کبھی ظاہر نہیں ہوتا۔ جو ظاہر ہوتا ہے وہ یہ ہے:

• اس کی کمٹمنٹ cm = H(CM, words)، یعنی ڈومین ٹیگ 4 کے تحت 28 ورڈز کا Poseidon2 ہیش، جو درخت میں ایک پتّے کے طور پر شامل کی جاتی ہے؛
• اس کا لفافہ، یعنی سادہ متن جو مالک کے ایڈریس کے لیے اس طرح مہر بند ہو کہ صرف مالک، یا اپنی خارجی مشاہداتی کلید کے ذریعے بھیجنے والا، اسے پڑھ سکے۔ چین 18 سے (چین 20 سمیت) لفافے میں ایک خفیہ کردہ میمو بھی ہوتا ہے۔ چند نوٹس، جنہیں چین عوامی فیلڈز سے حساب کرتی ہے، کوئی لفافہ نہیں رکھتے (نیچے)۔

نوٹ خرچ کرنے سے اس کا نلیفائر H(NF, nk, cm) شائع ہوتا ہے، جو مالک کی مشاہداتی کلید اور کمٹمنٹ کا ڈومین ٹیگ 3 کے تحت Poseidon2 ہیش ہے۔ nk کے بغیر کسی نلیفائر کو اس کی کمٹمنٹ سے نہیں جوڑا جا سکتا۔ نلیفائر سیٹ ہی دوہرے خرچ کو روکتا ہے۔

لفافہ

Envelope { kem_ct, to_receiver, to_sender, body }

ہر حصہ ChaCha20-Poly1305 ہے، جس کے شروع میں 12 بائٹ کا بے ترتیب نانس لگا ہوتا ہے اور ساتھ 16 بائٹ کا ٹیگ ہوتا ہے، اور منسلک ڈیٹا ایک ٹیگ (rand-envelope-receiver، rand-envelope-sender، rand-envelope-body) ہوتا ہے جس کے بعد نوٹ کی کمٹمنٹ آتی ہے، لہٰذا کوئی کلید ایسا لفافہ نہیں کھول سکتی جسے اس نے مہر بند نہ کیا ہو، اور کھولا گیا نوٹ اسی پتّے سے بندھا رہتا ہے جس کے تحت وہ موجود ہے۔ یہ 1,860 بائٹس سائفر ٹیکسٹ بنتا ہے؛ bincode کے لمبائی کے سابقے اسے وائر پر 1,892 کر دیتے ہیں۔ چین 20 کا جینیسس envelope_bytes: 1860 مقرر کرتا ہے، اور اس کا لیجر کسی بھی دوسری لمبائی کا نوٹ لفافہ مسترد کر دیتا ہے (envelope is 1348 bytes, this chain requires exactly 1860)؛ اس کے علاوہ وہ لفافے کے بارے میں کچھ نہیں جانچتا۔ چین 17 تک لفافے میں میمو فیلڈ نہیں تھی اور وہ 1,348 بائٹس (وائر پر 1,380) کا تھا، اور لیجر اس پر صرف 2,048 بائٹس کی حد لگاتا تھا، جو اب بھی ہر اس چین کا اصول ہے جس کے جینیسس میں envelope_bytes نہ ہو۔

میمو فیلڈ len (u16 LE) ‖ UTF-8 text ‖ zero padding ہے، 512 بائٹس، اس لیے متن زیادہ سے زیادہ 510 بائٹس ہو سکتا ہے۔ چین 20 پر ہر نوٹ لفافے میں یہ فیلڈ موجود ہوتی ہے، چاہے میمو ہو یا نہ ہو: چینج آؤٹ پٹ، فرضی آؤٹ پٹ اور بغیر میمو کی ادائیگی سب ایک ہی طرح پیڈ کیے جاتے ہیں، اور چین پر کوئی چیز میمو، اس کی لمبائی یا اس کی غیر موجودگی میں امتیاز نہیں کرتی۔ میمو نہ نوٹ میں ہے، نہ کمٹمنٹ میں، نہ کسی ثبوت میں۔ اسے ٹھیک وہی پڑھ سکتا ہے جو پہلے سے نوٹ پڑھ سکتا ہے: مالک، ovk کے ذریعے بھیجنے والا، یا کوئی بھی جسے اس آؤٹ پٹ کی TxKey دے دی جائے۔ خراب میمو فیلڈ (غلط لمبائی، ناجائز UTF-8، غیر صفر پیڈنگ) بغیر میمو کے طور پر کھلتی ہے اور مالک کو کبھی نوٹ سے محروم نہیں کرتی۔ میمو کسی کا بھی لکھا ہوا متن ہو سکتا ہے، کیونکہ کوئی بھی کسی عوامی ایڈریس پر ڈسٹ نوٹ بھیج سکتا ہے: اسے غیر معتبر کے طور پر دکھائیں اور کنٹرول اور یونیکوڈ فارمیٹ حروف تبدیل کر دیں، جیسا کہ rand والیٹ کرتا ہے۔ rand send --memo ادائیگی کے آؤٹ پٹ میں ایک میمو مہر بند کرتا ہے؛ rand notes --memo اور rand history --memo اسے دکھاتے ہیں۔

درخت، اینکرز اور ونڈوز

کمٹمنٹس ایک 32 گہرائی والے Poseidon2 درخت میں، قدیم ترین پہلے، شامل کی جاتی ہیں اور کبھی ہٹائی نہیں جاتیں۔ پتّا i وہ iواں نوٹ ہے جو چین نے اب تک بنایا؛ جینیسس ڈپازٹ نوٹس پہلے پتّے ہیں۔ ایک بنڈل، چاہے کچھ بھی منتقل کرے، چار پتّے اور چار نلیفائرز شامل کرتا ہے، فرضی بھی ان میں شامل ہیں۔ خالی پتّا مکمل صفر ہوتا ہے اور ایک گرہ H(NODE, left, right) ہوتی ہے (ڈومین ٹیگ 7)۔ ایک نوڈ صرف فرنٹیئر رکھتا ہے، لہٰذا کنسینسس اسٹیٹ میں پتّے کبھی نہیں ہوتے؛ rand_getWitness ضرورت پڑنے پر محفوظ شدہ پتّوں سے پورا درخت دوبارہ بناتا ہے، اسی لیے یہ وہ مہنگا ترین ریڈ ہے جو کوئی نوڈ فراہم کرتا ہے۔

ایک بنڈل اپنے ان پٹس کی رکنیت ایک اینکر کے مقابل ثابت کرتا ہے، جو درخت کی ایک جڑ ہے۔ دو اصول اینکر کو دیانت دار رکھتے ہیں:

دونوں ونڈوز 256 بلاکس کی ہوتی ہیں جب تک جینیسس proof_window_blocks (v0.6.8، 256 سے 4,096) مقرر نہ کرے، جو دونوں کو ایک ساتھ بدل دیتا ہے۔ چین 20 اسے 1,024 مقرر کرتی ہے؛ چین 14 سے 19 میں یہ فیلڈ نہیں تھی۔

ونڈوز اس لیے موجود ہیں کہ ثبوت بنانے میں حقیقی وقت لگتا ہے: درجہ 14 کا بنڈل ثبوت لیپ ٹاپ پر تقریباً 100 سیکنڈ میں ناپا گیا ہے (اور چین 17 سے والیٹ ایک دوسرا، درجہ 10 کا اجازتی ثبوت بھی بناتا ہے، تقریباً 7 سیکنڈ)۔ چین 18 کے 1.17 s کے بلاکس پر 256 بلاکس تقریباً پانچ منٹ بنتے تھے، اور ایک سست ثابت کنندہ پر تفویض شدہ ثبوت 294 s پر مسترد ہوا تھا؛ چین 20 کے 1,024 بلاکس، وہاں ایکسپلورر کے رپورٹ کردہ 1.34 s کے حساب سے، تقریباً 23 منٹ ہیں۔ جو والیٹ یہ دوڑ ہار جائے اسے anchor is not one of the last 1024 roots بتایا جاتا ہے اور وہ دوبارہ ثبوت بناتا ہے۔ rand_getAnchor بغیر پیرامیٹر کے ہیڈ کی بلاک اختتامی جڑ لوٹاتا ہے، جو واحد اینکر ہے جس پر کسی ثابت کنندہ کو ثبوت بنانا چاہیے۔

بنڈل

قدر منتقل کرنے والی ہر ٹرانزیکشن ٹھیک ایک مقررہ 4 ان پٹ اور 4 آؤٹ پٹ والا پوشیدہ اثاثہ بنڈل رکھتی ہے (چین 14 سے؛ چین 13 تک یہ 2 ان پٹ اور 2 آؤٹ پٹ والا تھا)، جسے پوشیدہ اثاثہ zkVM گیسٹ ثابت کرتا ہے، جس کا ڈائجسٹ hc_bundle جینیسس فائل میں مقرر ہے (60af094acfe65d85fdb18fb3d06cf9085dcf28c96e59e87f1ee527226e6e3fce، بنڈل گیسٹ v3، چین 17 سے 20 پر؛ چین 14 اور 15 پر یہ 83d3a3704a1fcdb9bae7136c0a947ffa34bd53f055388395ed705fe8cacd0ef8 تھا، گیسٹ v1):

Bundle { anchor, nullifiers[4], commitments[4], fee, burn_a, burn_r, burn_asset, time, envelopes[4], proof,
         auth_commit, auth_proof }     // the last two since chain 17

سلاٹس 0–1، ان پٹ اور آؤٹ پٹ دونوں میں، ایک نجی اثاثہ A رکھتے ہیں؛ سلاٹس 2–3 ہمیشہ RAND رکھتے ہیں۔ صرف RAND کی ادائیگی میں سلاٹس 0–1 فرضی ہوتے ہیں اور قدر اور فیس سلاٹس 2–3 سے گزرتی ہیں۔ ٹوکن کی منتقلی میں ٹوکن سلاٹس 0–1 سے گزرتا ہے اور RAND فیس اسی ثبوت کے سلاٹس 2–3 سے ادا ہوتی ہے۔ A ثبوت کا ایک وٹنس ورڈ ہے اور کسی عوامی فیلڈ میں موجود نہیں، اس لیے کسی بھی RPL ٹوکن کی منتقلی Action::None ہوتی ہے جس میں burn_a = burn_r = burn_asset = 0 ہوتا ہے، یعنی فیلڈ بہ فیلڈ RAND ادائیگی کی شکل۔

ثبوت یہ بیان کرتا ہے کہ ہر حقیقی ان پٹ anchor کے تحت ایک پتّا ہے اور اپنے سلاٹ کا اثاثہ رکھتا ہے، کہ چاروں نلیفائرز وہی ہیں جو شائع کیے گئے، کہ ہر گروپ متوازن ہے (نجی اثاثے میں in0 + in1 = out0 + out1 + burn_a، RAND میں in2 + in3 = out2 + out3 + fee + burn_r)، اور کہ خرچ کرنے والے کے پاس کلیدیں موجود ہیں — یہ ظاہر کیے بغیر کہ کون سے پتّے، کون سی رقوم، کون سا اثاثہ، یا کون۔ تینوں برن فیلڈز ہی پول سے نکلنے والی قدر کے بارے میں بنڈل کا واحد عوامی بیان ہیں: burn_a اور burn_asset صرف TokenBurn یا BridgeBurn پر غیر صفر ہوتے ہیں، جہاں وہ ایکشن کی رقم اور اثاثے کے برابر ہوتے ہیں؛ burn_r جلایا گیا RAND ہے، جو صرف Bond (اسٹیک) اور RegisterAggregator (بانڈ) پر غیر صفر ہوتا ہے۔ فیس ہمیشہ RAND میں ہوتی ہے۔

چین 17 سے خرچ کرنے کا اختیار دو ثبوتوں میں تقسیم ہے (منقسم اجازت)۔ بنڈل گیسٹ v3 مشاہداتی کلید nk اور ایک سالٹ لیتا ہے، جہاں پہلے کے گیسٹس خرچ کی کلید لیتے تھے: یہ pk_self = H(PK, nk) اخذ کرتا ہے، لازم کرتا ہے کہ ہر ان پٹ اسی کی ملکیت ہو، اور c = H(AUTH, nk ‖ salt) کو اس ڈائجسٹ میں شامل کرتا ہے جو یہ شائع کرتا ہے۔ ایک دوسرا گیسٹ، اجازتی گیسٹ (جینیسس hc_auth، 1e4e347f44cf86750b30a9a4bdf9ec9256efe353d4ff8017451eca7d195639c1)، خرچ کی کلید sk اور وہی سالٹ لیتا ہے، nk = H(NK, sk) اخذ کرتا ہے اور وہی c شائع کرتا ہے۔ بنڈل c کو auth_commit کے طور پر اور اجازتی گیسٹ کا درجہ 10 کا ثبوت auth_proof کے طور پر رکھتا ہے، اور لیجر لازم کرتا ہے کہ دونوں ثبوت ایک ہی ٹرانزیکشن بائنڈنگ کے مقابل تصدیق پائیں اور c کی دونوں قدریں یکساں ہوں۔ لہٰذا جس ثابت کنندہ کے پاس nk اور سالٹ ہو وہ بنڈل ثبوت تو بنا سکتا ہے مگر اجازتی ثبوت نہیں، اور تفویض شدہ ثبوت سازی اسی پر قائم ہے۔ سالٹ ہر بنڈل کے لیے 256 تازہ بے ترتیب بٹس ہوتا ہے، اس لیے auth_commit عوامی ہے اور کسی چیز کو آپس میں نہیں جوڑتا۔ جو والیٹ اپنا ثبوت خود بناتا ہے وہ بھی دونوں ثبوت بناتا ہے، اس لیے خود ثابت کردہ اور تفویض شدہ ٹرانزیکشن چین پر ایک جیسی دکھائی دیتی ہیں۔

شکل مقرر ہے، اس لیے خانے اکثر فرضی ہوتے ہیں: فرضی ان پٹ خرچ کنندہ کی ملکیت کا صفر قدر والا نوٹ ہوتا ہے (اس کا نلیفائر پھر بھی شائع ہوتا ہے)، فرضی آؤٹ پٹ صفر رقم کا نوٹ ہوتا ہے، اور بقایا آؤٹ پٹ اس وقت بھی موجود ہوتا ہے جب بقایا صفر ہو۔ جو ٹرانزیکشن بقایا نہ ہونے کی صورت میں مختلف دکھائی دیتی، وہ یہ افشا کر دیتی کہ بقایا تھا ہی نہیں۔ والیٹس کے لیے اس کا ایک نتیجہ: بنڈل کے دونوں گروپوں میں سے ہر ایک زیادہ سے زیادہ دو نوٹ خرچ کرتا ہے۔ RAND کی ادائیگی، بانڈ، ڈیپلائے یا کال زیادہ سے زیادہ دو RAND نوٹ خرچ کرتی ہے؛ ٹوکن کی منتقلی یا برن ٹوکن کے زیادہ سے زیادہ دو نوٹ اور فیس کے لیے زیادہ سے زیادہ دو RAND نوٹ خرچ کرتی ہے۔ ایک گروپ میں تین یا زیادہ نوٹوں پر پھیلی ہوئی قدر کو پہلے یکجا کرنا ہوتا ہے، اپنے ہی ایڈریس پر بھیج کر۔

چین 14 سے ثبوت اپنی ٹرانزیکشن کا پابند بھی ہے: یہ پوری ٹرانزیکشن کے ہیش پر، جس میں ثبوت خالی کر دیے گئے ہوں، بنایا جاتا ہے اور اسی کے مقابل تصدیق کیا جاتا ہے، اس لیے اسے کسی دوسرے ایکشن، دوسرے لفافوں یا دوسری چین پر نقل نہیں کیا جا سکتا؛ چین 20 پر یہ ہیش جینیسس ہیش کا بھی احاطہ کرتا ہے، اس لیے اسے ایسی چین پر بھی نقل نہیں کیا جا سکتا جس کی چین آئی ڈی یہی ہو (ٹرانزیکشنز)۔

کیا عوامی ہے اور کیا پوشیدہ

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

یہ جدول وہ بیان کرتا ہے جو چین 20 کے ثبوت چھپاتے ہیں، اور یہ ہمیشہ درست نہیں تھا۔ چین 14 اور 15 پر بنڈل ثبوت خود زیادہ ظاہر کرتا تھا (2026-09-27 کا zkVM جائزہ، INT-2 / GV-1): ہر جدول کا LogUp رننگ ٹوٹل بلائنڈنگ کے بغیر شائع ہوتا تھا، اور v1 گیسٹ فرضی ان پٹ کے لیے Merkle اور اثاثے کی جانچ چھوڑ دیتا تھا اور Merkle پاتھ کے ہر بٹ پر شاخ بندی کرتا تھا۔ چنانچہ کوئی بھی بنڈل ثبوت سے پڑھ سکتا تھا کہ چار ان پٹ خانوں میں سے کون سے حقیقی تھے، یوں یہ بھی کہ بنڈل نے ٹوکن منتقل کیا یا صرف RAND، اور یہ بھی کہ ہر خرچ شدہ لیف کے انڈیکس میں کتنے بٹ 1 ہیں۔ دو تبدیلیوں نے اسے بند کیا۔ چین 16 کنسٹرینٹ سیٹ 7 پر منتقل ہوئی، جو ہر LogUp ٹرمینل کو بلائنڈ کرتا ہے اور ہر اعلان شدہ جدول کی کم از کم حد 2^7 قطاریں مقرر کرتا ہے، اور ساتھ ہی شاخ بندی سے پاک بنڈل گیسٹ v2 پر منتقل ہوئی، جس میں ہر خانہ، فرضی ہو یا حقیقی، انہی ہدایات کے ذریعے مکمل رکنیت اور اثاثے کی جانچ چلاتا ہے۔ گیسٹ v3، جسے چین 17 تا 20 چلاتی ہیں، v2 والا ہی تعلق ہے جس میں خرچ کلید کی جگہ nk اور سالٹ ہیں، اور یہ بھی شاخ بندی سے پاک ہے۔ چین 14 اور 15 پر کمٹ ہونے والے بنڈلز جو افشا کر چکے، وہ افشا ہی رہے گا۔ چین 20 پر ثبوت اب بھی جو کچھ دکھاتا ہے وہ اس کا ہیڈر ہے: بنڈل کے لیے یہ ایک مقررہ شکل ہے (ٹیئر 14، ہر بنڈل پر 20,479 کی اعلان شدہ گیس حد)، اور Call یا Invoke کے لیے یہ ٹیئر، اعلان شدہ گیس حد، اور یہ کہ کال نے keccak یا sha256 پری کمپائل استعمال کیا یا نہیں اور تقریباً کتنی بار (ثبوت)۔

لفافے کے بغیر نوٹ

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

• برج فیس نوٹ (چین 20)۔ bridge.fees کے تحت چین ہر ڈپازٹ اور ہر برن پر جینیسس خزانے کے نام ایک zUSD نوٹ شامل کرتی ہے (RPL ٹوکنز)۔ اس کا کوئی لفافہ نہیں: اسٹوریج اسے ایک خالی لفافے کے ساتھ انڈیکس کرتی ہے جو کسی کے لیے سیل نہیں، اور rand_getCompactBlocks اور rand_getCommitments اسے اسی طرح دکھاتے ہیں، ڈپازٹ کا فیس نوٹ ڈپازٹ نوٹ کے بعد اور برن کا فیس نوٹ بنڈل کے چار نوٹوں کے بعد۔ نوٹ کا ہر لفظ عوامی ہے: رقم ٹرانزیکشن اور جینیسس کی شرح سے، اثاثہ اور time ٹرانزیکشن سے، from = 0، بلائنڈنگ ڈپازٹ کے لیے blake3("rand-bridge-fee-r-1" ‖ mu) یا برن کے لیے blake3("rand-bridge-burn-fee-r-1" ‖ txid)، اور مالک جینیسس کا recipient۔
• وہ نوٹ جن کا لفافہ کسی بات کا پابند نہیں۔ برج ڈپازٹ، ٹوکن منٹ، رجسٹریشن کا ابتدائی منٹ اور، چین 20 پر، انووک کی ادائیگیاں اور پروگرام منٹ ایسا لفافہ رکھتے ہیں جسے ٹرانزیکشن جمع کرانے والے نے سیل کیا ہو، لیکن چین نوٹ کو ایکشن کی عوامی فیلڈز سے شمار کرتی ہے اور لفافے کو اس کے مقابل کبھی نہیں جانچتی۔ لاپروا یا مخاصم جمع کنندہ لفافے میں بے معنی ڈیٹا سیل کر سکتا ہے، اس لیے وصول کنندہ کو اس پر انحصار نہیں کرنا چاہیے۔

اسی لیے rand والیٹ یہ نوٹ خود دوبارہ بناتا ہے (wallet::rebuilt_notes_with)۔ یہ کام آزمائشی ڈکرپشن کے ساتھ ساتھ ایک عوامی مرحلے میں ہوتا ہے: ہر ایسی ٹرانزیکشن کے لیے جس میں والیٹ کا اپنا pk درج ہو، اور فیس نوٹوں کے لیے جب اس کا ایڈریس خزانہ ہو، والیٹ نوٹ شمار کرتا ہے اور اسے اس لیف پر درج کرتا ہے جس کی کمٹمنٹ اس نوٹ کے ہیش سے مطابقت رکھتی ہو۔ دوبارہ بنایا گیا نوٹ محض ایک امیدوار ہے: جو نوڈ کسی ٹرانزیکشن، فیس کی شرح یا ہیش کے بارے میں جھوٹ بولے، وہ زیادہ سے زیادہ کسی نوٹ کو ملنے سے روک سکتا ہے، کبھی کوئی نوٹ کھاتے میں نہیں ڈال سکتا۔ v0.6.8 سے rand_getBlocks جو ہیڈرز لوٹاتا ہے ان کے public_notes میں ڈپازٹ، منٹ اور رجسٹریشن ٹرانزیکشنز ہوتی ہیں، اور برج فیس والی چین پر برنز بھی۔ یہ ثبوت ہٹا کر، اپنی اصل id کے تحت درج ہوتی ہیں، اس لیے یہ مرحلہ صرف ہیڈرز کے صفحات پڑھتا ہے۔ v0.6.8 میں انووکس public_notes میں شامل نہیں، اس لیے v0.6.8 نوڈ کے ساتھ والیٹ انووک کی ادائیگی صرف اس کے لفافے سے پاتا ہے، جسے انووک کرنے والا سیل کرتا ہے اور جس کی کوئی جانچ نہیں ہوتی۔ Fullnode main میں d0bb73fb سے انووکس بھی وہاں ثبوت ہٹا کر درج ہوتے ہیں۔ یہ صرف نوڈ کی تبدیلی ہے جو ابھی چین 20 کے فلیٹ پر نافذ نہیں ہوئی، اور والیٹ کو اس کے لیے کسی تبدیلی کی ضرورت نہیں۔

اسکیننگ: والیٹ اپنے نوٹ کیسے ڈھونڈتا ہے

نوڈ یہ جواب دیتا ہے کہ “یہ رہا پورا درخت”، کبھی یہ نہیں کہ “یہ رہا آپ کا بیلنس”۔ والیٹ یہ کام کرتا ہے:

1. لیفس کو صفحہ وار حاصل کرتا ہے، rand_getCommitments(from_index, limit) (فی کال زیادہ سے زیادہ 1,000) کے ذریعے یا فی بلاک اسٹریم rand_getCompactBlocks(from_height, to_height) (فی کال زیادہ سے زیادہ 128 بلاک) کے ذریعے؛ وہاں بنڈل رکھنے والی ہر ٹرانزیکشن چار نوٹ اور چار نلیفائر درج کرتی ہے، اور کوئی قاری فرضی خانے کو حقیقی خانے سے الگ نہیں پہچان سکتا؛
2. ہر لفافے کی آزمائشی ڈکرپشن کرتا ہے: وصول کنندہ کے طور پر اپنی ML-KEM ڈی کیپسولیشن کلید سے، اور بھیجنے والے کے طور پر ovk سے؛ وہ نوٹ رکھ لیتا ہے جن کا pk اس کا اپنا ہو؛ اور عوامی رقم والے نوٹ ان کی ٹرانزیکشنز سے دوبارہ بناتا ہے (اوپر)؛
3. ہر رکھے گئے نوٹ کا نلیفائر شمار کرتا ہے اور ان نوٹوں پر نشان لگاتا ہے جن کے نلیفائر rand_getNullifiers(from_height, limit) میں ظاہر ہوں؛
4. باقی نوٹوں کی رقم جمع کرتا ہے۔

rand_getTreeInfo بتاتا ہے کہ اسکین کرنے کو کتنا باقی ہے: { "next_index", "root", "nullifiers" }۔ خرچ کے لیے والیٹ کو ہر حقیقی ان پٹ کا 32 سطحی Merkle پاتھ درکار ہوتا ہے۔ rand والیٹ کمٹمنٹ درخت کی اپنی نقل رکھتا ہے، جو اسکین کے دوران انہی rand_getCommitments صفحات سے بنتی ہے، اور ہر پاتھ خود شمار کرتا ہے۔ اس لیے بھیجتے وقت والیٹ نوڈ سے درخت کے بارے میں صرف rand_getAnchor پوچھتا ہے، جس میں کسی لیف کا ذکر نہیں ہوتا۔ rand_getWitness(index) دوسرے کلائنٹس کے لیے نوڈ پر برقرار ہے۔ یہ نوڈ کو بتا دیتا ہے کہ کالر کون سا لیف خرچ کرنے والا ہے، اور مقامی درخت سے پہلے یہی پول کا سب سے بڑا افشا تھا۔ جس کلائنٹ کو اسے استعمال کرنا پڑے، اسے اپنا نوڈ چلانا چاہیے، یا مطلوبہ وٹنسز کے ساتھ وہ وٹنسز بھی مانگنے چاہییں جن کی اسے ضرورت نہیں۔

rand sync        # scanned 41 leaves and 37 blocks; 1 notes, 1 unspent
rand notes       # index, asset, amount, height, spent, pending, memo
rand history     # notes this wallet created for others, opened through ovk

ایک نوٹ rand send --no-wait اور اس کے بعد ہونے والے اُس پہلے sync کے درمیان pending رہتا ہے جو یا تو اس کا nullifier دیکھ لے یا time + window سے آگے کے بلاکس دیکھ لے (chain 20 پر 1,024، جو rand_getLimits.proof_window_blocks سے پڑھا جاتا ہے؛ اس کے بغیر 256)۔ اس کے بعد بنڈل کبھی قبول نہیں کیا جا سکتا اور نوٹ دوبارہ خرچ کے قابل ہو جاتا ہے۔