رسد

اس صفحے سے rand_getSupply کو درست طور پر پڑھنے اور اجرا کے بارے میں استدلال کرنے میں مدد لیں: RAND کہاں سے آتا ہے، کہاں جاتا ہے، اور وہ مساوات کیا ہے جو ایک پوشیدہ چین کی رسد کو بالکل درست رکھتی ہے، اگرچہ کوئی اس کے نوٹوں کو جمع نہیں کر سکتا۔

RAND کہاں سے آتا ہے اور کہاں جاتا ہے

ایک پوشیدہ چین اپنی رقم کا مجموعہ خود نہیں نکال سکتی، کیونکہ نوٹ کی قدر اس کے کمٹمنٹ کے اندر ہوتی ہے۔ عوامی صرف وہ ہے جو پول کی سرحد کو عبور کرتا ہے۔ ایسے عبور کی پانچ اقسام ہیں، اور پروگرام تجوریوں والی چین (RPL-2، چین 20) پر سات:

جس چین کا جینیسس tokens.burn_registration_fee مقرر کرتا ہے، جیسا کہ چین 20 کا کرتا ہے، وہاں ٹوکن رجسٹریشن کی 1 RAND کی registration_fee بھی burned کے ذریعے پول سے نکلتی ہے، مگر کسی رجسٹر اندراج میں داخل نہیں ہوتی: وہ تلف ہو جاتی ہے، اور تجویز کنندہ کو صرف بنڈل کی بنیادی فیس ملتی ہے۔

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

چین 20 پر نہ بلاک انعامات ہیں نہ افراطِ زر۔ چین کا پہلا طے شدہ اجرا بلاک ایگریگیشن سبسڈی ہے — ہر سیل شدہ بلاک پر نئے RAND کی گھٹتی ہوئی مقدار، جو اس ایگریگیٹر کو ادا ہوتی ہے جس کا ثبوت اس بلاک کا احاطہ کرتا ہے — اور یہ چین 20 پر فعال نہیں (ثبوت)۔ چین 20 ایک نئی چین ہے، جو 2026-10-01 کو 06:17 UTC پر فعال ہوئی، اور چین 19 سے کاٹی گئی (fullnode v0.6.8، ایک ہارڈ فورک)۔ اس کے جینیسس نے 31,184.243719258 RAND جاری کیے: 26,000 جینیسس کے 26 ویلیڈیٹرز میں اسٹیک شدہ اور 5,184.243719258 سات ڈپازٹ نوٹوں میں، جو چین 19 سے منتقل کیے گئے سات آپریٹر والیٹس کے بیلنس ہیں۔ چین 19 پر دیگر والیٹس کے پاس جو تھا، تقریباً 519.9 RAND (منظور شدہ وصول کنندگان کو فاؤسٹ منٹس، صارفین کو ادائیگیاں)، وہ منتقل نہیں کیا گیا، کیونکہ کوئی نوٹ اس کے مالک کے ایڈریس کے بغیر دوبارہ نہیں بنایا جا سکتا؛ اور نہ ہی ویلیڈیٹرز کے 0.499 RAND کے غیر نکالے گئے انعامات منتقل ہوئے۔ مزید دو جینیسس نوٹ، کل ملا کر نو، برج کے 99 zUSD (10 اور 89) رکھتے ہیں، جو RAND نہیں اور اس آڈٹ سے باہر ہیں۔ چین 20 پر rand_getSupply میں genesis_deposited کی قدر 5,184,243,719,258 اکائیاں اور invariant_holds: true درج ہے (بلندی 3,037، 2026-10-01)۔ چین 19، جو اسی دن چین 18 کے بلندی 141,935 پر لیے گئے اسنیپ شاٹ سے کاٹی گئی، نے 31,294.644359629 RAND جاری کیے: وہی 26,000 اسٹیک شدہ اور 5,294.644359629 سات نوٹوں میں، ساتھ میں 10 zUSD کا ایک نوٹ۔ اس کے بعد ہر فاؤسٹ منٹ جاری شدہ عدد میں اضافہ کرتا ہے، اور ہر جلائی گئی رجسٹریشن فیس اس میں سے کم کرتی ہے۔ چین 15، جو 2026-09-26 کو کاٹی گئی، نے جینیسس پر 23,000 RAND جاری کیے، 18,000 اٹھارہ ویلیڈیٹرز میں اسٹیک شدہ اور 5,000 پانچ نوٹوں میں؛ اس کے بعد کے آٹھ ویلیڈیٹرز نے موجودہ نوٹوں سے بانڈ کیا، جس سے کچھ جاری نہیں ہوا۔

ٹوکن اس آڈٹ سے باہر ہیں

اوپر کے عبور RAND کے ہیں۔ کوئی RPL ٹوکن، خواہ برج شدہ ہو یا مقامی، کبھی RAND کی سرحد عبور نہیں کرتا: اثاثہ اشاریہ 0 RAND کے لیے مخصوص ہے اور ٹوکن رجسٹری اسے کبھی تفویض نہیں کرتی، اس لیے BridgeAttest، TokenMint یا رجسٹریشن کا ابتدائی منٹ ہمیشہ کسی دوسرے اثاثے کا نوٹ جمع کرتا ہے، اور BridgeBurn یا TokenBurn کا burn_a ہمیشہ ایسا ہی نوٹ تلف کرتا ہے (burn_a کے ذریعے RAND جلانا مسترد کر دیا جاتا ہے)۔ fees_paid اور burned صرف بنڈل کی fee اور burn_r سے شمار ہوتے ہیں، اور پول کے اندر ٹوکن کی منتقلی کسی بھی کاؤنٹر کو حرکت نہیں دیتی، کیونکہ اس کا اثاثہ عوامی ہی نہیں ہوتا۔ چین 20 پر Invoke بھی burn_a کے ذریعے کوئی ٹوکن اندر لے سکتا ہے: پروگرام کی تجوری میں (deposit)، جس سے اس کی رسد میں کوئی تبدیلی نہیں آتی، یا تلف کر کے (burn)، صرف پروگرام کے اپنے ٹوکن کے لیے۔ برج کے فیس نوٹ (چین 20، ہر zUSD ڈپازٹ اور برن کا 10 bps، ایک خزانے کے ایڈریس پر) zUSD ہیں، کبھی RAND نہیں: جاری شدہ اور پشت پناہی والے، اس لیے ڈپازٹ پر پشت پناہی اور رسد دونوں مجموعی رقم سے بڑھتی ہیں اور برن پر amount − fee سے گھٹتی ہیں۔ کسی ٹوکن کی اپنی رسد رجسٹری کا عوامی شمار ہے: rand_getTokenSupply total_supply لوٹاتا ہے اور، برج شدہ ٹوکن کے لیے، ہر پشت پناہی کی locked رقم، جن کا مجموعہ اس کے برابر ہوتا ہے (RPL ٹوکن)۔

آڈٹ کی مساوات

اکائیوں میں چھ یک سمتی کاؤنٹر (1 RAND = 10⁹)، دو جو تلف شدہ کو درج کرتے ہیں، اور چین 20 پر پروگرام تجوریوں کے لیے دو:

pool_value     = genesis_deposited + faucet_minted + withdraw_deposited + program_rand_out − fees_paid − burned
register_total = Σ over the register of (stake + pending + rewards)
total_supply   = pool_value + register_total + program_rand_held
issued         = genesis_deposited + genesis_staked + faucet_minted

invariant:       total_supply == issued − slashed − registration_fees_burned

pool_value اندر آنے والی رقم منفی باہر جانے والی رقم ہے — یہ وہی عدد ہے جو نوٹوں کا مجموعہ ہے، جسے کوئی شمار نہیں کر سکتا۔ کسی ودڈرا کی 0.001 RAND کی بنیادی فیس عبور نہیں: یہ رجسٹر کی ایک قطار سے تجویز کنندہ کی قطار میں منتقل ہوتی ہے، اور صرف نوٹ نے سرحد عبور کی۔ invariant_holds کا غلط ہونا اتفاقِ رائے کی خرابی یا خراب ڈیٹابیس کی علامت ہے، کبھی کوئی جائز حالت نہیں۔ پروگرام تجوریوں کے بغیر چین پر دونوں پروگرام اجزا صفر ہوتے ہیں، اس لیے وہاں مساوات چین 19 والی ہی ہے۔ جینیسس کا vesting سیکشن، جو اب تک کسی چین میں نہیں رہا، اسی طرح ایک تیسرا عوامی رجسٹر شامل کرے گا (JSON-RPC)۔

ایک ایسی چین پر جس نے 2,000 جمع اور 4,000 اسٹیک کیے، 1,000 RAND کے ایک بانڈ اور ایک ودڈرا کے ذریعے مرحلہ وار:

اسے پڑھنا

curl -s http://127.0.0.1:8545 -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"rand_getSupply","params":[]}'

{ "height": 1998,
  "genesis_deposited": "2000000000000", "genesis_staked": "4000000000000",
  "faucet_minted": "0", "withdraw_deposited": "999999000000",
  "fees_paid": "1000000", "burned": "1000000000000",
  "slashed": "0", "registration_fees_burned": "0",
  "pool_value": "1999998000000", "register_total": "4000002000000",
  "total_supply": "6000000000000", "invariant_holds": true }

ہر رقم اکائیوں کی اعشاری اسٹرنگ ہے، کیونکہ JSON عدد 2⁵³ سے آگے درست صحیح عدد نہیں رہتا۔ مکمل آبجیکٹ میں یہاں دکھائے گئے سے زیادہ فیلڈز ہیں، جن میں فاؤسٹ کا فی ایپوک جوڑا faucet_epoch اور faucet_minted_in_epoch شامل ہے، جسے چین 20 اپنے بجٹ کے مقابلے میں جانچتی ہے، program_rand_out اور program_rand_held (v0.6.8 سے)، اور چار vesting_* کاؤنٹر جو چین 20 پر "0" دکھاتے ہیں، کیونکہ اس کے جینیسس میں vesting سیکشن نہیں (JSON-RPC)۔ ایکسپلورر یہی آبجیکٹ GET /supply پر اور نمایاں اعداد GET /stats میں فراہم کرتا ہے۔

یہ کتنا درست ہے

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

دو اندراجات پہلے ایک دعوے پر قائم تھے، اور چین 14 دونوں کو جانچ میں بدل دیتی ہے (آڈٹ v3، POOL-1):

• فاؤسیٹ کا Mint نوٹ کی کشائی ساتھ رکھتا ہے۔ cm اور amount کے ساتھ یہ عمل pk، time اور r بھی شائع کرتا ہے۔ داخلے کے وقت (pk, no sender, amount, asset 0, time, r) کا کمٹمنٹ دوبارہ شمار کیا جاتا ہے۔ عدم مطابقت پر اسے the mint's commitment does not open to its published note and amount کے ساتھ رد کر دیا جاتا ہے، اور time کو بنڈل کی مدت کے اندر رہنا لازم ہے۔ منٹ کرنے والا ساتوں فیلڈز پر ڈومین rand-mint-2 کے تحت دستخط کرتا ہے۔ اس سے پہلے کوئی ویلیڈیٹر ایک رقم شائع کر کے کسی دوسری مالیت کا نوٹ مہر بند کر سکتا تھا۔ اس کی قیمت یہ ہے کہ فاؤسیٹ نوٹ کے مالک کا pk عوامی ہوتا ہے، جیسے کسی انخلا کی ادائیگی عوامی ہوتی ہے۔ rand_mint کے پیرامیٹرز میں کوئی تبدیلی نہیں ہوئی۔
• جینیسس کا alloc نوٹ بھی اپنی کشائی ساتھ رکھتا ہے۔ جس چین میں tokens سیکشن موجود ہو، وہاں ہر قطار { cm, envelope, amount, opening: { pk, time, r } } ہوتی ہے۔ نوڈ کمٹمنٹ دوبارہ شمار کرتا ہے، اثاثہ 0 پر، الا یہ کہ کشائی کسی درج شدہ ٹوکن کا asset بتائے۔ جس جینیسس فائل کا cm مطابقت نہ رکھے، نوڈ اسے رد کر دیتا ہے۔ genesis_deposited میں صرف اثاثہ 0 کی قطاریں شمار ہوتی ہیں۔ مبہم cm ہی وہ واحد راستہ تھا جس سے جینیسس کا مصنف کسی بھی اثاثے کا بے ضمانت نوٹ پول میں ڈال سکتا تھا اور کوئی اس کی جانچ نہیں کر سکتا تھا۔ چنانچہ فائل شائع ہونے کے بعد جینیسس نوٹ کا مالک اور رقم ارادتاً عوامی ہوتے ہیں۔ صرف یہ بات نجی رہتی ہے کہ بعد میں اسے کب اور کس میں خرچ کیا گیا۔ rand-node genesis کشائی ہمیشہ لکھتا ہے۔

جو چین tokens سیکشن کے بغیر قائم کی گئی ہو، اس پر پرانا قاعدہ ہی لاگو رہتا ہے: genesis_deposited اعلان شدہ amount فیلڈز کا مجموعہ ہے، اور اس پر جینیسس فائل کی بنیاد پر اعتماد کیا جاتا ہے۔ جینیسس کی دونوں رقمیں جینیسس ہیش میں شامل ہیں، اس لیے دونوں صورتوں میں ہر نوڈ ان پر متفق رہتا ہے۔

یہ کاؤنٹر جان بوجھ کر اتفاقِ رائے کی حالت کا حصہ نہیں بنائے گئے، کیونکہ اسٹیٹ روٹ انہیں ہیش نہیں کرتا۔ rand-node verify --mode quick چین کو دوبارہ چلا کر ان میں سے ہر ایک کو دوبارہ شمار کرتا ہے، اور اگر محفوظ شدہ اسنیپ شاٹ مختلف ہو تو عدم مطابقت کی اطلاع دیتا ہے۔