کمانڈ لائن

تین بائنریز cargo build --release سے بنتی ہیں: rand-node (نوڈ اور آپریٹر کمانڈز)، rand (پوشیدہ والیٹ) اور rand-prover (تفویض کردہ ثبوت ساز)۔ ہر کمانڈ -h/--help قبول کرتی ہے۔ یہ صفحہ v0.6.8 ریلیز (c9c9bd3c) کو بیان کرتا ہے، وہ بلڈ جس پر chain 20 چلتی ہے؛ جہاں v0.6.7 کا رویہ مختلف تھا، وہاں اس کی صراحت کی گئی ہے۔ v0.6.8 سے پرانا rand والیٹ chain 20 پر ترسیل نہیں کر سکتا، کیونکہ اس کا جینیسس ہر ثبوت اور ہر دستخط شدہ پیغام کو اپنے ہیش سے منسلک کرتا ہے۔ پہلی دو بائنریز مختلف قسم کی کلیدیں رکھتی ہیں: نوڈ کلید ایک Dilithium2 کلیدی جوڑا ہے جو بلاکس پر دستخط کرتا ہے؛ والیٹ کلید ایک پوشیدہ خرچ کلید ہے جو چین پر کسی چیز پر دستخط نہیں کرتی۔

rand-node

rand-node <COMMAND>
  keygen      Generate a new Dilithium2 key file (refuses to overwrite an existing one)
  address     Print the address, public key, and libp2p peer id of a key file
  genesis     Write a genesis.json: every validator key is staked, each --alloc becomes a deposit note
  alloc-note  Print one genesis alloc note as JSON, RAND or a listed token, for splicing into a genesis
  init        Initialise a data directory from a genesis file
  run         Run the node
  verify      Verify the chain in a data directory without running the node
  db          Database maintenance on a stopped node's data directory
  safety      status | clear-halt | release-lock: a stopped validator's consensus safety state
  status      Show node status
  register    Print this node's Registration, for the wallet that bonds it in
  admit       sign | submit: the validator set's vote to admit a new key (admission by vote)
  unbond      Move bonded stake into unbonding
  withdraw    Pay released stake and rewards into a note at the payout address
  bridge-gov  rotate-pq | rotate-pause | cancel-rotation: the bridge's post-quantum rotations
  vesting     status | claim | revoke | bond | unbond: genesis vesting (chains with a vesting section)
  aggregator  register | unbond | withdraw — the aggregator role (aggregation chains only)
  aggregate   The aggregate daemon (aggregation chains only)

safety، admit اور bridge-gov v0.6.8 میں نئی ہیں۔ کوئی balance اور کوئی transfer موجود نہیں: منتقلی کے لیے پوشیدہ خرچ کلید درکار ہے، جو صرف والیٹ کے پاس ہوتی ہے۔

ایک عمومی فلیگ، --allow-test-fri-profile (یا RAND_ALLOW_TEST_FRI_PROFILE=1)، init، run اور verify کو ایسا جینیسس قبول کرنے دیتا ہے جس کا fri_profile test ہو۔ یہ پروفائل تقریباً 17 بٹ کی درستی فراہم کرتا ہے، اور جینیسس فائل لکھنے والا کوئی بھی اسے نامزد کر سکتا ہے، اس لیے v0.6.8 سے نوڈ اس فلیگ کے بغیر ایسا جینیسس مسترد کر دیتا ہے۔ ٹیسٹ سوئٹس اسے سیٹ کرتے ہیں؛ کسی اور کو نہیں کرنا چاہیے۔

keygen، address

keygen موڈ 0600 کے ساتھ { "seed": <32-byte hex>, "address": <base58>, "public_key": <hex> } لکھتی ہے۔ یہ فائل بیج کی واحد نقل ہے۔ v0.6.8 سے keygen پہلے سے موجود --out کو مسترد کر دیتی ہے (… already exists or cannot be created; refusing to overwrite a key file) اور اسے جوں کا توں چھوڑ دیتی ہے؛ کوئی --force نہیں ہے، اس لیے اسے بدلنے کے لیے پرانی فائل کو ایک طرف منتقل کریں۔ v0.6.7 اور اس سے پہلے کے ورژن اسے پوچھے بغیر اوور رائٹ کر دیتے تھے۔ address address، public_key (1,312 بائٹ hex) اور peer_id پرنٹ کرتی ہے۔

genesis

ہر --alloc کے لیے ایک alloc سطر پرنٹ کرتی ہے، پھر جینیسس ہیش، ویلیڈیٹر اور نوٹ کی تعداد، ایپاک کی لمبائی، پانچ حدیں، hc_bundle اور hc_auth (--auth-guest کے بغیر none)، پھر گیس کی سطر: gas: price P/gas, B/KiB, bundle limit N, dynamic: target … B / … gas, adjust … bps, floor …/…, ceiling …/…, byte load all|paying، یا --gas-price کے بغیر gas: none، اور --program-state-cell-fee کے ساتھ ایک program_state: cell fee N RAND سطر۔ init بھی یہی گیس سطر پرنٹ کرتی ہے۔ پانچوں حد فلیگ یکساں برتاؤ کرتے ہیں: چھوڑ دینے پر فائل میں ایسی کوئی فیلڈ نہیں ہوتی اور چین پہلے سے طے شدہ قدر پر چلتی ہے؛ دیے جانے پر فیلڈ جینیسس ہیش کا حصہ ہوتی ہے، خواہ اس کی قدر پہلے سے طے شدہ ہی ہو۔ chain 20 ان فلیگز کے ساتھ بنائی گئی (deploy/cut-chain20-genesis.sh):

--max-program-words 65535 --max-proof-bytes 4194304 --max-block-bytes 20971520 \
--max-call-envelope-bytes 65536 --max-program-public-words 32768 \
--tokens tokens.json \
--bundle-guest v3 --auth-guest --hardening-v6 \
--gas-price 100 --byte-price 800 --bundle-gas-limit 20479 --gas-dynamic 10485760,262144,1250 \
--max-gas-price 10000 --max-byte-price 80000 --gas-byte-load paying \
--envelope-bytes 1860 \
--testnet --binding-domain 1 --proof-window-blocks 1024 --program-state-cell-fee 10000000 \
--epoch-blocks 1000 --faucet --fri-profile production

چینز 18 اور 19 انہی فلیگز کے ساتھ --envelope-bytes 1860 تک کاٹی گئیں، اور v0.6.8 کے فلیگز میں سے کوئی بھی استعمال نہیں ہوا۔ پروف کی حد 4 MiB ہے، جو چینز 13 تا 16 کی 8 MiB سے کم ہے: تقسیم شدہ اجازت والی ٹرانزیکشن میں زیادہ سے زیادہ تین پروف ہوتے ہیں، اور 3 × 4 MiB + 1 MiB بیس MiB کے بلاک میں سما جاتے ہیں۔ tokens.json میں 1 RAND کی registration_fee، 10000000000000 کی mint_cap_per_day، max_tokens 4096، burn_registration_fee اور bound_note_value ہیں، اور zUSD اپنی سات پشت پناہیوں کے ساتھ درج ہے۔ کوئی --bridge فلیگ نہیں ہے، اور کٹ اسکرپٹ اب بھی bridge، staking اور consensus_domain سیکشنز بعد میں فائل میں جوڑتا ہے (چین 20 پر: برج گارڈین سیٹ 1 پر، آٹھ PQ گارڈین کلیدوں، توقف کلید، rules_v2، rotation اور fees کے ساتھ؛ staking سیکشن، فاسٹ کی اجازت فہرست، admission_by_vote اور 2,500 bps کے داخلہ بجٹ کے ساتھ؛ consensus_domain: 1؛ اور zUSD کے جینیسس نوٹ، جو alloc-note --asset 1 --envelope-bytes 1860 سے بنائے گئے)۔ معتبر جینیسس ہیش وہی ہے جو init مکمل فائل پر چھاپتا ہے۔

ہر --alloc نئی کمٹمنٹ رینڈمنیس کے ساتھ ایک ڈپازٹ نوٹ بناتا ہے، اس لیے دو بار کاٹنے سے دو مختلف ہیش بنتے ہیں۔ کمانڈ ہمیشہ نوٹ کا اوپننگ cm اور amount کے ساتھ لکھتی ہے، جو tokens سیکشن والی چین کے لیے لازم ہے:

"alloc": [
  { "cm": "<64 hex>",
    "envelope": { "kem_ct": "<hex>", "to_receiver": "<hex>", "to_sender": "<hex>", "body": "<hex>" },
    "amount": 1000000000000,
    "opening": { "pk": "<64 hex>", "time": 0, "r": "<64 hex>" } }
]

چنانچہ فائل شائع ہونے کے بعد جینیسس نوٹ کا مالک اور رقم ڈیزائن کے مطابق عوامی ہوتے ہیں؛ صرف یہ نجی رہتا ہے کہ اسے بعد میں کب اور کس میں خرچ کیا گیا۔ جینیسس ایک بار کاٹیں اور فائل محفوظ رکھیں۔

alloc-note

--to <rand1…> (لازمی)، --amount <N> (لازمی)، --asset <INDEX> (طے شدہ 0)، --envelope-bytes <N> (طے شدہ: پرانا فارمیٹ)۔ ایک الاٹ نوٹ JSON کی صورت میں چھاپتی ہے، جو --to کے لیے اسی طرح مہربند ہوتا ہے جیسے genesis --alloc کرتا ہے۔ جو جینیسس envelope_bytes مقرر کرتا ہے وہ مطابقت رکھنے والے --envelope-bytes کے بغیر مہربند نوٹ کو مسترد کر دیتا ہے۔ --amount اثاثے کی پوری اکائیوں میں ہے: RAND کے لیے نو اعشاریے، برج شدہ ٹوکن کے لیے آٹھ (اثاثہ 1 پر 10 کا مطلب 10 zUSD ہے)۔ کسی درج ٹوکن کے نوٹ کے لیے ضروری ہے کہ اس ٹوکن کی پشت پناہیوں کی locked رقوم کا مجموعہ ٹھیک اس کے نوٹوں کے برابر ہو۔

init

جینیسس ہیش اور وہی gas: سطر چھاپتی ہے جو genesis چھاپتی ہے۔

run

ماحول: RUST_LOG (طے شدہ info,libp2p=warn,libp2p_mdns=off)۔ Ctrl-C یا SIGTERM نوڈ کو صاف طریقے سے بند کرتا ہے۔

عوامی اینڈپوائنٹ https://rpc.randprotocol.org ایک آرکائیو نوڈ کے سامنے اجازت فہرست والی پراکسی ہے؛ 2026-10-01 سے اس کی اجازت فہرست عوامی سامع کا میتھڈ سیٹ ہے۔

safety

رکے ہوئے ویلیڈیٹر کی اتفاق رائے سے متعلق حفاظتی حالت (v0.6.8)۔ ہر کمانڈ ڈیٹا ڈائریکٹری خود کھولتی ہے، اس لیے کوئی بھی چلتے ہوئے نوڈ کے ساتھ نہیں چلتی۔

rand-node safety status       --datadir <dir>
rand-node safety clear-halt   --datadir <dir> --i-have-compared-this-node-with-the-fleet
rand-node safety release-lock --datadir <dir> --i-give-up-this-validators-lock

status کمٹ شدہ ہیڈ، ویو اور آخری ووٹ شدہ ویو، سب سے اونچا QC، آیا ویلیڈیٹر اپنے ہیڈ سے اوپر لاک ہے، اور کوئی بھی درج شدہ حفاظتی تعطل چھاپتا ہے۔ جو نوڈ دیکھے کہ ایک تصدیق شدہ تین-چین کسی ایسے بلاک کو کمٹ کرنے کی کوشش کر رہی ہے جو اس کے اپنے کمٹ شدہ ہیڈ کی نسل سے نہیں، وہ رک جاتا ہے اور اسے درج کر لیتا ہے (audit v6, CON-5)؛ اس کے بعد run اس ریکارڈ کے ساتھ بند ہو جاتا ہے جب تک clear-halt نہ کیا جائے۔ صاف کرنے سے پہلے اس نوڈ کا ہیڈ دو دیگر ویلیڈیٹرز کے ہیڈ سے ملائیں، اور فرق ہو تو کسی آرکائیو سے دوبارہ سنک کریں۔ v0.6.8 (CON-4) سے “موجود نہیں” جوابات کا کوئی کورم اب لاک نہیں کھولتا: جو ویلیڈیٹر کسی ایسے بلاک پر لاک ہو جو اسے حاصل نہ ہو سکے، وہ خاموش رہتا ہے جب تک ایسی تجویز نہ آئے جس کا justify لاک سے بالاتر ہو یا بلاک حاصل نہ ہو جائے۔ release-lock محفوظ شدہ لاک کو کمٹ شدہ ہیڈ کے سرٹیفکیٹ تک گھٹا دیتا ہے؛ اسے ایک وقت میں ایک ہی ویلیڈیٹر پر استعمال کریں، اور صرف تب جب بلاک ہمیشہ کے لیے ضائع ہو چکا ہو۔ اپنے تصدیقی فلیگ کے بغیر ہر لکھنے والی کمانڈ صرف یہ چھاپتی ہے کہ وہ کیا کرے گی، اور کچھ تبدیل نہیں کرتی۔

verify

ہم آہنگ ہو تو ایگزٹ کوڈ 0، اور --repair کے بغیر کوئی مسئلہ ملے تو 2۔

db

db drop-receipts-index --datadir <DATADIR>، نوڈ رکا ہوا ہو: v0.3 سے پہلے کے بلڈ پر واپس جانے سے پہلے receipts_by_program انڈیکس حذف کریں، کیونکہ وہ بلڈ اس انڈیکس والا ڈیٹا بیس نہیں کھول سکتا۔ اگلا آغاز رسیدوں سے انڈیکس دوبارہ بنا دیتا ہے۔

status

--rpc <URL> (طے شدہ http://127.0.0.1:8545)۔ rand_status کو جوں کا توں چھاپتی ہے۔

register، unbond، withdraw

admit sign|submit

ووٹ کے ذریعے داخلہ (v0.6.8)۔ جس چین کا genesis staking.admission_by_vote مقرر کرتا ہے، جیسا کہ chain 20 کا کرتا ہے، اس پر نئی ویلیڈیٹر کلید صرف اس وقت رجسٹر ہوتی ہے جب ووٹنگ وزن کے دو تہائی سے قطعی زیادہ کے حامل ویلیڈیٹر اس کے داخلے پر دستخط کر چکے ہوں۔

امیدوار وہ کلید ہے جو رجسٹریشن میں درج ہوگی؛ rand-node address --key اسے پرنٹ کرتی ہے، اور register کا پرنٹ کردہ hex اسے رکھتا ہے۔ داخلہ کمٹ ہونے کے بعد بانڈ پہلے کی طرح ہوتا ہے (rand bond … --registration) اور اسے استعمال کر لیتا ہے۔ rand_getAdmitted داخل شدہ اور منتظر کلیدوں کی فہرست دیتا ہے۔

bridge-gov

برج کی پوسٹ کوانٹم تبدیلیاں (v0.6.8)، نگہبانوں اور توقف کلید کے حامل کے لیے۔ ہر مرحلہ chain id، اس کا پابند ڈومین اور rand_getBridgeState.rotation_nonce کو --rpc سے پڑھتا ہے (طے شدہ http://127.0.0.1:8545)۔

--new-key ایک hex Dilithium2 عوامی کلید ہے، یا ایک ایسی @file جس میں وہ ہو، یا @key-file (اس کی عوامی کلید)۔ دستخطی سطریں index:hex ہیں، خالی جگہ یا نئی سطر سے جدا، اور # تبصروں کی اجازت ہے۔

vesting status|claim|revoke|bond|unbond

وقت سے مقفل genesis تخصیص میں حامل اور منسوخ کنندہ کا حصہ، ایسی چین پر جس کے genesis میں vesting حصہ ہو۔ chain 20 کے genesis میں ایسا کوئی حصہ نہیں۔ کلید ایک rand-node keygen فائل ہے۔

aggregator register|unbond|withdraw, aggregate

aggregation حصے والی چین کے لیے ایگریگیٹر کے کردار کی کمانڈز: aggregator register --key --bond <RAND> --payout <rand1…> --rpc ایک دستخط شدہ AggregatorRegistration پرنٹ کرتی ہے؛ aggregator unbond اور aggregator withdraw ویلیڈیٹر کی جوڑی کا عکس ہیں۔ aggregate --key <KEY> [--rpc <URL>] [--watch] [--interval-secs 15] [--no-wait] وہ ڈیمن ہے جو rand_getUnsealed کو بار بار جانچتا ہے، ایک مجموعی ثبوت بناتا ہے اور اسے جمع کراتا ہے۔ chain 20 پر غیر فعال ہے، جس کے genesis میں aggregation حصہ نہیں۔

rand (والیٹ)

عمومی آپشنز، ذیلی کمانڈ سے پہلے یا بعد میں:

رقوم اعشاری RAND میں ہوتی ہیں، زیادہ سے زیادہ نو اعشاریہ مقامات تک (1، 1.5، .25، 0.000000001)۔ send، token mint اور token burn پر، اور randpay: لنک میں، ٹوکن کی رقم ٹوکن کی نمائشی اکائیوں میں ہوتی ہے، اس کی رجسٹری قطار کے اپنے decimals کے مطابق (zUSD کا 10 یعنی 10 zUSD)۔ bridge-burn، token create --fixed-supply اور --initial ٹوکن کی سب سے چھوٹی اکائی میں سادہ صحیح اعداد لیتی ہیں، اور asset-balance انہی کو پرنٹ کرتی ہے۔ جہاں بھی کوئی کمانڈ ٹوکن لیتی ہے، وہ رجسٹری اشاریہ، rpl1… id یا 64-hex id لیتی ہے؛ id کو اس کے اشاریے میں نوڈ کی پوری رجسٹری فہرست (rand_getTokens، ہر صفحہ) سے حل کیا جاتا ہے، فی ٹوکن تلاش سے کبھی نہیں، کیونکہ وہ نوڈ کو بتا دے گی کہ کون سا ٹوکن منتقل ہونے والا ہے۔ عددی اشاریہ نوڈ تک پہنچتا ہی نہیں۔

--cuda کے لیے ایسا build درکار ہے جو --features cuda کے ساتھ بنایا گیا ہو، اور اس کا کوئی متبادل راستہ نہیں؛ اب تک کوئی PTX تیار نہیں کیا گیا۔ یہ call-input envelope کو seal نہیں کر سکتا: rand call --cuda کے لیے --no-envelope ضروری ہے۔ یہ صرف gas کی بالائی حد کا اعلان کرتا ہے، اور --gas-limit N کو مسترد کر دیتا ہے۔

CLI جو بھی memo اور رابطے کا نام دکھاتا ہے (send کی تصدیق، notes، history، tx-key)، وہ پہلے ایک ہی نمائشی قاعدے سے گزرتا ہے: کنٹرول حروف، Unicode کے فارمیٹ حروف (bidi کنٹرول، صفر چوڑائی والے حروف، soft hyphen) اور U+2028/U+2029 کو U+FFFD کے طور پر دکھایا جاتا ہے، اور مسلسل وقفہ جاتی حروف کو ایک وقفے کے طور پر۔

پہلی shielded منتقلی

rand keygen                                   # wallet.key.json
rand address                                  # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderr
rand faucet                                   # testnet, allowlisted wallets only: 100 RAND into a note only you can open
rand balance                                  # balance: 100 RAND
rand send rand1q9f… 1.5                       # asks to confirm, then a minute and a half to two minutes of local proving, then the commit
rand notes                                    # the spent note, and the change note

پتہ اور memo کا اشتراک

rand address --uri --amount 1.5 --memo "invoice #42" --qr   # a randpay: link, as a terminal QR
rand contacts add alice rand1q9f…                           # shows the fingerprint, asks add? [y/N]
rand send alice 1.5 --memo "coffee"                         # the memo is sealed into the payment output
rand history --memo                                         # alice's row shows the whole memo
rand tx-key <hash>                                          # hand the sent row's key to alice or an auditor

memo اسی سربمہر body کے اندر ہوتا ہے جس میں note ہوتا ہے، اس لیے جو ایک کو کھول سکتا ہے وہ دوسرے کو بھی کھول سکتا ہے: وصول کنندہ notes کے ذریعے، اور ہر وہ شخص جس کے پاس اس output کی فی ٹرانزیکشن کلید ہو، rand_checkTransaction <hash> <key> کے ذریعے۔ Chain 18 پہلی chain ہے جس کا genesis envelope_bytes مقرر کرتا ہے؛ chains 14 سے 17 پر --memo کسی بھی ثبوت کی تیاری سے پہلے ہی مسترد کر دیا جاتا تھا۔

ایک خفیہ call جسے آپ بعد میں دوبارہ کھول سکتے ہیں

rand program build --guest balance_check --arg 1000 --out bc.json
rand program deploy bc.json                   # prints the program id
rand call <id> --input 100 --input 200 --input 300 --input 400
rand open-call <txhash>                       # inputs: [100, 200, 300, 400] — verdict: faithful (exit 0)

ایک stateful پروگرام: RPL-2 کاؤنٹر

ایسی chain پر جس میں program_state حصہ موجود ہو، جیسا کہ chain 20 میں ہے۔ کاؤنٹر صرف وہی transitions قبول کرتا ہے جو ایک cell کو پڑھیں اور اسے اس کے پہلے لفظ میں ایک کا اضافہ کر کے واپس لکھیں؛ transition میں باقی سب کچھ (bundle جو جمع کرتا ہے، vault جو ادا کرتا ہے، پروگرام جو mint کرتا ہے) بغیر جانچ کے ساتھ چلا جاتا ہے، جس کی وجہ سے یہ ایک مظاہرہ ہے، ایسا پروگرام نہیں جس کے پیچھے قدر رکھی جائے۔

rand program build --guest rpl2_counter --out counter.json
rand program deploy counter.json                          # prints the program id
rand token create --name "Counter Share" --symbol CTR --decimals 0 --program <id>   # say index 2
rand program state <id> --cell 0100000000000000000000000000000000000000000000000000000000000000   # 64 zeros: absent
cat > step.json <<'JSON'
{ "reads":  [{ "key": "0100…00", "value": "0000…00" }],
  "writes": [{ "key": "0100…00", "value": "0100…00" }],
  "deposit": { "rand": "500000000", "kind": "none" },
  "pays":   [{ "asset": 0, "amount": "200000000", "to": "rand1…" }],
  "mints":  [{ "asset": 2, "amount": "1" }] }
JSON
rand program invoke <id> --transition step.json           # exit 3 if the cell moved since; re-read and retry
rand program vault <id>                                   # asset 0: 300000000 units (0.5 RAND in, 0.2 out)

فائل میں … پورے 64 hex حروف کی جگہ ہیں، جو wallet کے لیے لازمی ہیں۔

deploy اور call کیا دکھاتے ہیں

منقسم اجازت والی chain پر ہر bundle دو ثبوتوں پر مشتمل ہوتا ہے جو اسی مشین پر بنائے جاتے ہیں: tier-10 کی خرچ کی اجازت اور tier-14 کا bundle۔ chain 18 پر rand v0.6.7 کے ساتھ ایک program deploy، 2026-09-30:

proving the spend authorisation on this machine (tier 10; seconds)…
authorisation proved in 6.8s: tier 10, 1368908 bytes
proving the bundle (tier 14; about a minute and a half on a laptop)…
proved in 116.7s: tier 14, 1500710 bytes
submitted deploy <hash>
  0 RAND out, 59.8545 RAND change, fee 0.1007 RAND, anchored at height 97831, proved in 116.7s (bundle) + 6.8s (auth)

ایک call اپنے call ثبوت سے پہلے اپنی gas اور فیس دکھاتا ہے، پھر ادائیگی والے bundle کا ثبوت اسی طرح تیار کرتا ہے:

proving the call locally (90 inputs stay private, over the program's 11-word public input)…
gas: 5636 (declaring 6144, tier 12)
fee 0.006191437 RAND (incl. two price steps of headroom)
proved in 29.2s: tier 12, 3346865 bytes, outputs [...]

یہاں 6,144 دراصل 5,636 ہے جسے 2^10 کے قریب ترین بڑے مضرب تک بڑھایا گیا ہے، اور rand fee call 12 --gas 6144 --bytes <B> اس حد کی قیمت tip کی قیمتوں پر بغیر کسی اضافی گنجائش کے لگاتا ہے۔

rand-prover

تفویض کردہ prover اپنی الگ binary کی صورت میں: یہ کسی wallet کا tier-14 bundle ثبوت کسی دوسری مشین پر تیار کرتا ہے۔ rand-node run --prover یہی سروس ایک node کے اندر چلاتا ہے۔ ہر ذیلی کمانڈ --home <DIR> لیتی ہے (env RAND_PROVER_HOME، طے شدہ ~/.rand-prover)، یعنی وہ ڈائرکٹری جس میں prover.key.json اور pairings.json ہوتے ہیں۔

chain 20 پر prover کو wallet کی viewing key nk اور ایک تازہ salt موصول ہوتے ہیں۔ یہ خرچ نہیں کر سکتا، لیکن وہ سب کچھ پڑھ سکتا ہے جو اس wallet نے کبھی وصول کیا یا بھیجا: صرف ایسے prover سے pairing کریں جسے آپ اپنی تاریخ دکھانے پر آمادہ ہوں۔ wallet واپس ملنے والے ہر ثبوت کی جانچ کرتا ہے۔

کلیدی فائلوں کے فارمیٹ

Node کلید:

{ "seed": "hex of 32 bytes", "address": "base58 of blake3(\"rand-address\" || public key)", "public_key": "hex of 1312-byte Dilithium2 public key" }

Wallet کلید، ورژن 2:

{ "version": 2, "spend_key": "hex of 8 little-endian u32 words (64 characters)" }

rand keygen اسے mode 0600 کے ساتھ لکھتا ہے، اور v0.6.8 سے ہر rand کمانڈ ایسی wallet کلید فائل کو مسترد کر دیتی ہے جسے group یا other پڑھ سکیں: ہاتھ سے کاپی یا بحال کی گئی کلید کو دوبارہ 0600 پر سیٹ کرنا ضروری ہے (chmod 600 <key>)۔ wallet کلید کھونے سے وہ تمام notes ضائع ہو جاتے ہیں جنہیں وہ کھول سکتی تھی؛ اس ریلیز میں کوئی recovery phrase نہیں ہے۔