اکاؤنٹس اور پتے

اس صفحے کو کام کے مطابق درست کلید بنانے، کسی ایڈریس کو پارس کرنے یا اس کی توثیق کرنے، اور یہ جاننے کے لیے استعمال کریں کہ کسی کو کلید سونپنے سے کیا ظاہر ہوتا ہے۔ اس چین پر کوئی اکاؤنٹ نہیں ہیں: بیلنس کسی کلیدی فائل سے متعلق حقیقت ہے، چین سے متعلق کبھی نہیں۔

دو کلیدیں، دو قسم کے ایڈریس

دونوں کبھی آپس میں نہیں ملتیں۔ ویلیڈیٹرز کی شناخت پہلی قسم سے ہوتی ہے، اور یہی Dilithium2 کلیدی ساخت کسی ٹوکن کی Key اجرائی اتھارٹی (rand token create --authority-key-out rand-node keygen کی ساخت والی فائل لکھتا ہے)، برج کی توقف کلید اور اس کی چھ پوسٹ کوانٹم نگہبان کلیدوں کے لیے بھی کام آتی ہے۔ نگہبانوں کی تصدیقی کلیدیں secp256k1 ہیں، جن کے ساتھ Ethereum طرز کے 20 بائٹ ایڈریس ہوتے ہیں (برج)۔ قدر دوسری قسم کے تحت رکھی جاتی ہے۔

شفاف ایڈریس

نوڈ کلید 32 بائٹ کا ایک سیڈ ہے جس سے Dilithium2 کلیدی جوڑا متعین طریقے سے اخذ کیا جاتا ہے: 1,312 بائٹ کی عوامی کلید اور 2,420 بائٹ کے دستخط۔ ایڈریس عوامی کلید کا ڈومین سے علیحدہ کیا گیا BLAKE3 ہیش ہے، جو base58 میں پیش کیا جاتا ہے:

address = blake3("rand-address" || public_key)      // 32 bytes, shown as base58

دستخط شدہ اشیاء (ووٹ، بلاکس، اجرا، اسٹیکنگ کارروائیاں) پوری عوامی کلید ساتھ رکھتی ہیں، اس لیے تصدیق کنندہ محض ایڈریس پر بھروسا کرنے کے بجائے blake3("rand-address" || public_key) == address کی جانچ کرتا ہے۔ یہی سیڈ نوڈ کی libp2p شناخت بھی دیتا ہے، یعنی blake3("rand-p2p-identity" || seed) سے حاصل ہونے والی ایک ed25519 کلید، جو بوٹ اسٹریپ multiaddr میں /p2p/ کے بعد آنے والی پیئر شناخت ہے۔

rand-node keygen --out node.key.json      # prints the address
rand-node address --key node.key.json     # address, public key (hex), libp2p peer id

مثال: EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e چین 20 کے ویلیڈیٹرز میں سے ایک ہے۔ چین 15 سے 20 تک وہی اٹھارہ کلیدیں دوبارہ استعمال کرتی ہیں جو چین 14 کے لیے بدلی گئی تھیں، اس لیے ان کے ایڈریس اور پیئر شناختیں تبدیل نہیں ہوئیں اور چین 13 کا کوئی ویلیڈیٹر ایڈریس یا پیئر شناخت اب استعمال میں نہیں؛ چین 15 پر آٹھ مزید ویلیڈیٹرز بانڈ ہو کر شامل ہوئے، اور چین 16 سے تمام 26 جینیسس فائل میں ہیں۔

شیلڈڈ ایڈریس

والیٹ ایک ہی راز ہے، یعنی 256 بٹ کی خرچ کلید sk، اور باقی سب کچھ اسی سے اخذ ہوتا ہے۔ اشتقاق Poseidon2 ہے جس میں ڈومین ٹیگ پہلا جذب شدہ لفظ ہوتا ہے (H(domain, msg))، یعنی وہی فنکشن جس کا حساب zkVM سرکٹ کے اندر کرتا ہے:

spend key   sk                          256 bits, in wallet.key.json
   │
   ├─ viewing key   nk = H(NK, sk)      sees the whole history; cannot spend
   │     ├─ pk = H(PK, nk)              the field a note names its owner by
   │     ├─ nullifier(cm) = H(NF, nk, cm)   what a spend publishes
   │     ├─ ovk                         opens envelopes this wallet sent
   │     └─ ML-KEM-768 decapsulation key    opens envelopes sent to this wallet
   └─ address   rand1 + base58(pk || kem_ek)

ایڈریس pk کے 32 بائٹس ہیں جن کے بعد 1,184 بائٹ کی ML-KEM-768 انکیپسولیشن کلید آتی ہے، اور یہ rand1 سابقے کے بعد base58 میں لکھا جاتا ہے: 1,665 یا 1,666 حروف (base58 لمبائی ابتدائی بائٹس پر منحصر ہے؛ تقریباً چودہ میں سے ایک ایڈریس چھوٹا ہوتا ہے)، تقریباً 1.6 KB، اور کوئی چیک سم نہیں۔ بھیجنے والے کو نوٹ کا لفافہ سربمہر کرنے کے لیے انکیپسولیشن کلید درکار ہوتی ہے، اسی لیے وہ ایڈریس میں شامل ہے۔ یہ ارادتاً عوامی ہے: کوئی بھی اس پر ادائیگی کر سکتا ہے، اور اسے رکھنے سے یہ کچھ ظاہر نہیں ہوتا کہ اس میں کیا ہے۔

rand keygen                      # wallet.key.json; refuses to overwrite an existing file
rand address                     # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderr

v0.5.10 سے rand address stdout پر بالکل ایڈریس اور ایک نئی سطر چھاپتا ہے، اس لیے $(rand address) اسکرپٹ میں کام کرتا ہے۔ فنگرپرنٹ stderr پر جاتا ہے۔

پارسنگ، بالکل اسی طرح جیسے ShieldedAddress::parse کرتا ہے: rand1 ہٹائیں، base58 سے ڈی کوڈ کریں، اور بالکل 32 + 1,184 = 1,216 بائٹس لازم کریں؛ پہلے 32 بائٹس pk ہیں، آٹھ لٹل اینڈین u32 الفاظ کی صورت میں، اور باقی انکیپسولیشن کلید۔ RPC پارس کرنے سے پہلے ہی 2,000 حروف سے لمبا کوئی بھی پیرامیٹر مسترد کر دیتا ہے۔

کلیدی فائل کے ساتھ والیٹ <key>.key.json.notes.json رکھتا ہے، جو ان نوٹس کا کیش ہے جو اس کلید نے کھولے ہیں۔ اس میں نوٹس کا سادہ متن ہوتا ہے، اس لیے اسے کلید کی طرح موڈ 0600 میں لکھا جاتا ہے؛ اس کی ہر قطار لیف 0 سے دوبارہ اسکین کر کے بازیاب کی جا سکتی ہے۔

ایڈریس کا اشتراک: فنگرپرنٹ اور randpay: لنکس

ایڈریس اتنا لمبا ہے کہ اسے بلند آواز سے پڑھا یا آنکھ سے موازنہ نہیں کیا جا سکتا، اور اس میں کوئی چیک سم نہیں، اس لیے v0.5.10 سے ہر والیٹ اس کے ساتھ ایک فنگرپرنٹ دکھاتا ہے۔ فنگرپرنٹ صرف دکھانے کے لیے ہے: نہ چین پر اور نہ نیٹ ورک پر کوئی چیز اسے ساتھ رکھتی ہے۔

fingerprint = first 80 bits of blake3("rand-address-fingerprint-1" || pk_bytes || kem_ek)
            = 16 Crockford base32 characters, shown as XXXX-XXXX-XXXX-XXXX

ہیش ان 1,216 خام بائٹس پر لیا جاتا ہے جنہیں ایڈریس انکوڈ کرتا ہے۔ حروفِ تہجی 0123456789ABCDEFGHJKMNPQRSTVWXYZ ہیں؛ پارسنگ حروف کے چھوٹے بڑے ہونے اور ہائفن کو نظر انداز کرتی ہے اور O کو 0 اور I یا L کو 1 پڑھتی ہے۔

randpay: لنک ایک ایڈریس اور، اختیاری طور پر، اسے کی جانے والی ادائیگی کی تفصیل ساتھ رکھتا ہے:

randpay:<rand1…>[?amount=<decimal>][&asset=<index | 64 hex | rpl1…>][&memo=<percent-encoded UTF-8>]

amount اثاثے کی نمائشی اکائیوں میں ہوتی ہے (RAND نو اعشاری مقامات تک اعشاری صورت میں، ٹوکن اپنی رجسٹری قطار کے اپنے decimals کے مطابق) اور صفر نہیں ہونی چاہیے۔ memo زیادہ سے زیادہ 510 بائٹس UTF-8 ہے۔ اسکیم کا میل حروف کے چھوٹے بڑے ہونے سے قطع نظر کیا جاتا ہے؛ نامعلوم پیرامیٹر، دہرایا گیا پیرامیٹر، یا غلط پرسنٹ انکوڈنگ مسترد کر دی جاتی ہے۔

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"                          # to a contact, with a memo

rand send <TO> ایک rand1… ایڈریس، ایک randpay: لنک یا کسی محفوظ کردہ رابطے کا نام قبول کرتا ہے، اور انہیں اسی ترتیب سے آزماتا ہے۔ لنک کے amount، asset اور memo وہ چیزیں پُر کرتے ہیں جو کمانڈ لائن چھوڑ دے، اور دونوں طریقوں سے دی گئی کوئی قدر اگر مختلف ہو تو مسترد کر دی جاتی ہے۔ ثبوت بنانے سے پہلے send to <contact, if any> · fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <asset> چھاپتا ہے اور تصدیق مانگتا ہے؛ اسکرپٹ --yes دیتا ہے۔ رابطے کلید کے ساتھ <key>.contacts.json میں، موڈ 0600 میں، محفوظ ہوتے ہیں۔ میمو نوٹ کے لفافے کے اندر سفر کرتا ہے (نوٹس)۔

نہ کوئی rand balance <address> ہے اور نہ کوئی بیلنس RPC: چین کسی کے لیے بھی اس کا جواب نہیں دے سکتی۔ والیٹ اپنی مشاہداتی کلید سے چین کے ہر لفافے کو اسکین کر کے اپنا بیلنس نکالتا ہے (نوٹس)۔

کلیدیں جو آپ کسی اور کو سونپ سکتے ہیں

افشا کلیدوں کی خاصیت ہے، اور چین اس میں سے کچھ بھی لازم نہیں کر سکتی۔

مشاہداتی کلید خرچ نہیں کر سکتی۔ چین 17 (منقسم اجازت) سے بنڈل ثبوت خود nk سے بنتا ہے، اور ہر بنڈل ایک دوسرا، چھوٹا اجازتی ثبوت بھی ساتھ رکھتا ہے جو صرف خرچ کلید بنا سکتی ہے اور جو اسی ایک ٹرانزیکشن سے بندھا ہوتا ہے (نوٹس)۔ اسی بنا پر کسی تفویض شدہ ثابت کنندہ کو nk، اور یوں والیٹ کی پوری تاریخ، سونپی جا سکتی ہے بغیر اس کے کہ وہ خرچ کر سکے؛ والیٹ اجازتی ثبوت ہمیشہ اپنی مشین پر بناتا ہے۔ اس تقسیم سے ایڈریس، کلیدیں اور موجودہ نوٹس تبدیل نہیں ہوتے۔ والیٹ ہر بار چلنے پر nk اخذ کرتا ہے اور اسے کبھی محفوظ نہیں کرتا؛ ہر TxKey ہر لفافے کے لیے نئی بنائی جاتی ہے اور سربمہر کرنے کے بعد ضائع کر دی جاتی ہے۔ کسی نوڈ کو rand_importViewingKey کے ذریعے مشاہداتی کلید سونپی جا سکتی ہے (میموری میں، فی نوڈ زیادہ سے زیادہ 64، ری اسٹارٹ پر ختم) تاکہ وہ حامل کی جانب سے اسکین کرے — ایکسپلورر یہی طریقہ استعمال کرتا ہے — اور rand_checkTransaction(hash, key) ایک بے حالت کال میں ایک ادائیگی کو کسی TxKey کے مقابل جانچتا ہے۔ rand viewing-key nk چھاپتا ہے، اور rand tx-key <hash> اس ٹرانزیکشن کے ہر آؤٹ پٹ کی کلید چھاپتا ہے جسے یہ والیٹ کھول سکتا ہے۔

ٹوکن شناخت کنندے ایڈریس نہیں ہیں

RPL ٹوکن کا ایک تیسری قسم کا متنی شناخت کنندہ ہوتا ہے، اور وہ کسی ٹوکن کی نشاندہی کرتا ہے، کبھی کسی حامل کی نہیں۔ ٹوکن کی 32 بائٹ کی اثاثہ شناخت 64 hex حروف کی صورت میں اور rpl1… کی صورت میں دکھائی جاتی ہے: یعنی 32 شناختی بائٹس پر bech32m (BIP-350)، جس کا انسانی قابلِ مطالعہ حصہ rpl ہے، 52 ڈیٹا حروف اور 6 حروف کا چیک سم، کُل 62 حروف۔ پارسنگ سخت ہے: غلط چیک سم، کوئی دوسرا انسانی قابلِ مطالعہ حصہ، ایسا پے لوڈ جو بالکل 32 بائٹس نہ ہو، یا چھوٹے بڑے ملے جلے حروف مسترد کر دیے جاتے ہیں، اس لیے ٹائپنگ کی کوئی غلطی کبھی کسی دوسرے ٹوکن تک نہیں پہنچتی۔ نوٹ یہ شناخت ساتھ نہیں رکھتا؛ اس کا asset لفظ ٹوکن کا گنجان رجسٹری اشاریہ ہے (RPL ٹوکنز)۔

برج وصول کنندہ

برج کے وائر فارمیٹ میں وصول کنندہ کے لیے 32 بائٹ کا خانہ ہے، اور شیلڈڈ ایڈریس اس میں نہیں سماتا۔ فی الحال یہ خانہ ایڈریس کا ایک ہیش رکھتا ہے:

recipient_hash = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)

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

مختصر شیلڈڈ ایڈریس: چین 11 پر آزمایا گیا، واپس لیا گیا

چین 11 (fullnode ٹیگ v0.2، 2026-09-17) نے طویل پتے کی جگہ 53 سے 55 حروف پر مشتمل وصول کنندہ شناخت متعارف کرائی، یعنی rand1 + base58(blake3(وصول کنندہ کی دستخطی کلید) ‖ checksum)، اور ML-KEM انکیپسولیشن کلید کو ایک دستخط شدہ وصول کنندہ ریکارڈ میں منتقل کر دیا، جسے بھیجنے والا ایکسپلورر کی رجسٹری سے حاصل کرتا تھا یا ادائیگی کی درخواست کے اندر ہی وصول کرتا تھا۔ یہ ایک دن چلی اور اسی دن واپس لے لی گئی (fullnode 17db41d)؛ چین 12 طویل پتے پر واپس آ گئی، بالکل اسی طرح جیسے اوپر بیان کیا گیا ہے، اور اس کے بعد کی ہر چین، بشمول چین 20، اسی کو برقرار رکھتی ہے۔

اسے کیوں ہٹایا گیا۔ وصول کنندہ شناخت ایک ہیش ہے، اور بھیجنے والا کسی ہیش کے لیے نوٹ سیل نہیں کر سکتا۔ ایسے والیٹ کو پہلی ادائیگی کے لیے، جس نے کبھی رجسٹریشن نہ کرائی ہو، ضروری تھا کہ وصول کنندہ ادائیگی کی درخواست یا ریکارڈ فائل فراہم کرے، اور خود رجسٹریشن کی فیس خود کو منتقلی کے ذریعے ادا ہوتی تھی، جو ایک نیا، خالی والیٹ نہیں کر سکتا۔ ترسیل کے دونوں راستے رجسٹری کو یہ بھی بتا دیتے تھے کہ کسے ادائیگی ہونے والی ہے۔ وہ ڈیزائن جو مختصر پتہ، غیر مشروط طور پر رقم بھیجنے کی صلاحیت اور خفیہ نگاری پر مبنی رازداری تینوں کو برقرار رکھتا ہے، ایک ہائبرڈ پتہ ہے: 32 بائٹ کی X25519 کلید پتے کے اندر (تقریباً 93 حروف)، پوسٹ کوانٹم کلید تلاش کے ذریعے، جس میں غیر رجسٹر شدہ والیٹ کو پہلی ادائیگی کلاسیکی مخالفین کے مقابلے میں خفیہ رہتی ہے اور بعد کی ہر ادائیگی مکمل طور پر پوسٹ کوانٹم ہوتی ہے۔ اس کی تفصیل آگے دی گئی ہے؛ جب تک یہ جاری نہیں ہوتا، طویل پتہ ہی پتہ ہے۔

چین 11 کی تفصیلات اور اس کا نفاذ fullnode کی تاریخ میں (docs/superpowers/specs/2026-09-17-short-shielded-address.md، ٹیگ v0.2) ان حصوں کے لیے محفوظ رہتے ہیں جنہیں ہائبرڈ ڈیزائن دوبارہ استعمال کرتا ہے: اخذ شدہ وصول کنندہ دستخطی کلید، دستخط شدہ ریکارڈ اور اس کا تصدیق کنندہ، اور چین اسٹیٹ کے طور پر رجسٹری۔