Rand Protocol
لاسوندونه
بنسټیز مفاهیم

نوټونه او د ژمنو ونه

هغه نوټ ماډل چې هر انتقال پرې ولاړ دی - ژمنې، باطلوونکي، لفافې، د 32 ژورتیا لرونکې ونه، لنګرونه او د لنګر او وخت کړکۍ - او دا چې والټ څنګه خپل نوټونه لټوي.

دا پاڼه د هر هغه څه د جوړولو یا پلټنې لپاره وکاروئ چې حوض لولي: یو والټ چې خپل نوټونه لټوي، یو انډېکسر چې ژمنې او باطلوونکي تعقیبوي، یا یوه وسیله چې ګوري یوه معامله څه خپروي. پر دې زنځیر ارزښت د نوټونو یوه ټولګه ده؛ زنځیر د هغوی ژمنې ساتي، هېڅکله یې منځپانګه نه.

یو نوټ

یو نوټ { 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 }
برخهبایټهدا څه دی
kem_ct1,088د ترلاسه کوونکي پتې ته د ML-KEM-768 کپسول‌بندي
to_receiver60د هرې معاملې کیلي TxKey چې د کپسول شوي راز لاندې نغښتل شوې
to_sender60همدا TxKey چې د لېږونکي د وتونکې لید کیلي ovk لاندې نغښتل شوې
body652112 بایټه نوټ او د 512 بایټو د یادښت ساحه د TxKey لاندې (تر 17م زنځیر پورې 140 بایټه، یوازې نوټ)

هره برخه 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، غیر صفري ډکول) د بې یادښته په توګه پرانیستل کېږي او هېڅکله مالک له نوټ څخه نه محروموي. یادښت د هر چا متن دی، ځکه هر څوک کولای شي یوې عامه پتې ته یو ډېر کوچنی نوټ تادیه کړي: د باور نه وړ په توګه یې وښایئ، د کنټرول او Unicode د بڼې توري بدل کړئ، لکه څنګه چې د rand والټ یې کوي. rand send --memo یو یادښت د تادیې په وتنه کې مهر کوي؛ rand notes --memo او rand history --memo یې ښیي.

ونه، لنګرونه او کړکۍ

ژمنې یوې 32 ژورې Poseidon2 ونې ته ورزیاتېږي، تر ټولو زړې لومړی، او هېڅکله نه لرې کېږي. پاڼه i هغه i-م نوټ دی چې زنځیر تر اوسه جوړ کړی؛ د جنیسس د زیرمې نوټونه لومړنۍ پاڼې دي. یو بنډل څلور پاڼې او څلور باطلوونکي ورزیاتوي، هر څه چې لېږدوي، ډمي په ګډون. تشه پاڼه ټوله صفرونه ده او یوه غوټه H(NODE, left, right) ده (ډومېن ټګ 7). یو نوډ یوازې سرحد ساتي، نو د اجماع حالت هېڅکله پاڼې نه ساتي؛ rand_getWitness د غوښتنې پر مهال بشپړه ونه له زېرمه شویو پاڼو بیا جوړوي، له همدې امله دا تر ټولو ګرانه لوستنه ده چې یو نوډ یې وړاندې کوي.

یو بنډل د خپلو ننوتنو غړیتوب د یوه لنګر، د ونې د یوې ریښې، په وړاندې ثابتوي. دوه قاعدې لنګر صادق ساتي:

ثابتارزښتقاعده
ANCHOR_WINDOW256 بلاکه؛ پر 20م زنځیر 1,024لنګر باید د وروستیو window د بلاک د پای ریښو څخه یوه وي؛ هغه ریښه چې ونه یې د بلاک په منځ کې تېروي هېڅکله لنګر نه دی
TIME_WINDOW256 بلاکه؛ پر 20م زنځیر 1,024د بنډل time باید د [height − window, height] دننه وي

دواړه کړکۍ 256 بلاکه دي مګر دا چې جنیسس proof_window_blocks وټاکي (v0.6.8، له 256 تر 4,096)، چې دواړه یوځای بدلوي. 20م زنځیر 1,024 ټاکي؛ له 14م تر 19م زنځیرونو دا ساحه نه درلوده.

کړکۍ ځکه شته چې ثبوت جوړول ریښتینی وخت نیسي: د tier-14 بنډل ثبوت پر لپټاپ شاوخوا 100 ثانیې اندازه شوی (او له 17م زنځیر راهیسې والټ دویم، tier-10 د اجازې ثبوت جوړوي، شاوخوا 7 ثانیې). 256 بلاکه د 18م زنځیر په 1.17 s بلاکونو کې شاوخوا پنځه دقیقې وو، او پر یوه ورو ثبوت جوړونکي یو استازي شوی ثبوت په 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 په خصوصي شتمنۍ کې، in2 + in3 = out2 + out3 + fee + burn_r په RAND کې)، او چې لګوونکی کیلي لري — پرته له دې چې څرګنده کړي کومې پاڼې، کوم مقدارونه، کومه شتمني، یا څوک. د سوځولو درې ساحې له حوض څخه د وتونکي ارزښت په اړه د بنډل یوازینی عامه بیان دی: 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 په توګه او د اجازې ګیسټ tier-10 ثبوت د auth_proof په توګه لېږدوي، او لېجر غواړي چې دواړه ثبوتونه د همغې معاملې د تړون په وړاندې تایید شي او د c دواړه ارزښتونه سره سم وي. نو یو ثبوت جوړونکی چې nk او سالټ لري کولای شي د بنډل ثبوت جوړ کړي خو د اجازې ثبوت نه، او استازي شوی ثبوت جوړول پر همدې ولاړ دی. سالټ په هر بنډل کې 256 تازه تصادفي بټونه دي، نو auth_commit عامه دی او هېڅ شی نه تړي. هغه والټ چې خپله ثبوت جوړوي هم دواړه ثبوتونه جوړوي، نو پر ځان ثابت شوې او استازي شوې معامله پر زنځیر یو شان ښکاري.

شکل ثابت دی، نو ځایونه اکثره ډمي وي: ډمي ننوتنه د صفر ارزښت لرونکی نوټ دی چې د لګوونکي ملکیت وي (باطلوونکی یې بیا هم خپرېږي)، ډمي وتنه د صفر مقدار لرونکی نوټ دی، او د پاتې پیسو وتنه هغه مهال هم شته وي چې پاتې پیسې صفر وي. هغه راکړه ورکړه چې د پاتې پیسو د نشتوالي په صورت کې بل ډول ښکاره شي، دا به افشا کړي چې پاتې پیسې نه وې. د والټونو لپاره پایله: د یوه بنډل هره یوه له دوو ډلو څخه تر ټولو ډېر دوه نوټونه لګوي. د RAND تادیه، ضمانت، ځای پر ځای کول یا غوښتنه تر ټولو ډېر دوه RAND نوټونه لګوي؛ د ټوکن لېږد یا سوځول د ټوکن تر ټولو ډېر دوه نوټونه او د فیس لپاره تر ټولو ډېر دوه RAND نوټونه لګوي. هغه ارزښت چې په یوه ډله کې په درېیو یا ډېرو نوټونو وېشل شوی وي، باید لومړی د خپل پتې ته د لېږد له لارې یوځای شي.

له 14 چین راهیسې ثبوت له خپلې راکړې ورکړې سره هم تړل شوی دی: د ټولې راکړې ورکړې پر هغه هش جوړېږي او ورسره تاییدېږي چې ثبوتونه پکې خالي شوي وي، نو بل عمل، نورو لفافو یا بل چین ته نه شي کاپي کېدای؛ په 20 چین کې دا هش د جینیسس هش هم رانغاړي، نو هغه چین ته هم نه شي کاپي کېدای چې ورته chain id لري (راکړې ورکړې).

څه عام دي او څه پټ

پر چین عامپټ
لېږد، د RAND یا د هر RPL ټوکنلنګر، ټول څلور باطلوونکي، ټولې څلور ژمنې، فیس، burn_a = burn_r = burn_asset = 0، time، د څلورو لفافو کوډ شوي متنونه، ثبوت، auth_commit او د اجازې ثبوتچا لېږلی، چا ته تادیه کېږي، مقدار، یادښت، کومه شتمني خوځېدلې، پاتې پیسې، کومې پاڼې لګول شوې، کوم ځایونه ډمي وو
د ټوکن سوځول یا د پل سوځولهر هغه څه چې لېږد یې خپروي، او burn_asset او burn_a د عمل له شتمنۍ او مقدار سره برابر (او د پل د سوځولو لپاره، د رېلې کوونکي فیس، ملاتړی ټوکن او منزل)کوم نوټونه سوځول شوي، او چا سوځولي
د faucet مینټژمنه، لفافه، مقدار، مینټ کوونکی تصدیقوونکی، او له 14 چین راهیسې د نوټ پرانیستنه (pk، time، r)، چې منل ورڅخه ژمنه بیا محاسبه کويد نوټ هر وروستی لګښت
د جینیسس زېرمه{ cm, envelope, amount, opening: { pk, time, r } } د جینیسس په فایل کې، او د لېست شوي ټوکن د نوټ لپاره په پرانیستنه کې asset (د 20 چین جینیسس دوه zUSD نوټونه لري): د مالک pk، مقدار او شتمني په قصدي ډول عام ديکله او په څه کې وروسته لګول کېږي
ایستنه، د پل زېرمه، د ټوکن مینټ یا د ثبت لومړنی مینټمقدار، ترلاسه کوونکی، د نوټ time او پټوونکی r (چین پخپله ژمنه محاسبه کوي)د نوټ هر وروستی لګښت
د invoke تادیه یا د پروګرام مینټ (20 چین)مقدار، شتمني، ترلاسه کوونکی او r؛ د نوټ time د بنډل دید نوټ هر وروستی لګښت
د پل د فیس نوټ (20 چین)مقدار، شتمني او time، مشتق شوی پټوونکی، د جینیسس خزانه د مالک په توګه، او لفافه نه لريد نوټ هر وروستی لګښت

ارزښت په عام مقدار سره حوض ته ننوځي — د faucet مینټ، د جینیسس زېرمه، د تصدیقوونکي ایستنه، د پل تصدیق او د هغه د فیس نوټ، د ټوکن مینټ، د پروګرام د والټ تادیه — او د عام فیس یا سوځولو په توګه ترې وځي. د دې ترمنځ هر څه نوټ دی.

جدول هغه څه ښيي چې د 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 چین کې، د invoke تادیې او د پروګرام مینټونه هغه لفافه لري چې د راکړې ورکړې سپارونکي مهر کړې ده، خو چین نوټ د عمل له عامو ساحو محاسبه کوي او هېڅکله لفافه ورسره نه پرتله کوي. بې‌پروا یا دښمن سپارونکی کولای شي بې‌معنا شی مهر کړي، نو ترلاسه کوونکی باید پرې تکیه ونه کړي.

له همدې امله د rand والټ دا نوټونه پخپله بیا جوړوي (wallet::rebuilt_notes_with)، د ازمایښتي ډیکریپټ تر څنګ په یوه عامه دوره کې: د هرې داسې راکړې ورکړې لپاره چې خپل pk یې یاد کړی وي، او د فیس نوټونو لپاره کله چې د هغه پته خزانه وي، نوټ محاسبه کوي او په هغه پاڼه کې یې ثبتوي چې ژمنه یې ورته هش کېږي. بیا جوړ شوی نوټ یوازې کاندید دی: هغه نوډ چې د راکړې ورکړې، د فیس نرخ یا هش په اړه دروغ وايي، نوټ ناموندلی پرېږدي، هېڅکله یې نه کریډیټ کوي. له v0.6.8 راهیسې هغه سرلیکونه چې rand_getBlocks یې بېرته ورکوي، د زېرمې، مینټ او ثبت راکړې ورکړې په public_notes کې لري، او د پل فیس لرونکي چین پر سر سوځول هم، له ثبوتونو پرته، د خپل اصلي id لاندې، نو دوره یوازې د سرلیک پاڼې لولي. په v0.6.8 کې invokes په public_notes کې نه دي، نو د v0.6.8 نوډ په وړاندې والټ د invoke تادیه یوازې د هغې د لفافې له لارې مومي، چې invoke کوونکی یې مهر کوي او هېڅ یې نه ازمويي. د fullnode main له d0bb73fb راهیسې invokes هم هلته لري، له ثبوتونو پرته؛ دا یوازې د نوډ بدلون دی، لا د 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 وي چې یا یې باطلوونکی وویني یا له time + window څخه وروسته بلاکونه (په زنځیر 20 کې 1,024، چې له rand_getLimits.proof_window_blocks څخه لوستل کیږي؛ له هغه پرته 256)؛ له دې وروسته بنډل هېڅکله نه منل کیږي او نوټ بیا د لګښت وړ ګرځي.

وروستی ځل د 2026-10-12 په نېټه د fullnode د c0878c3f کمېټ (زنځیره 21) پر وړاندې تایید شوی. چېرې چې کوډ او دا پاڼه سره توپیر ولري، کوډ سم دی؛ موږ ته خبر راکړئ.