ٹرانزیکشنز اور ایکشنز

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

ٹرانزیکشن

Transaction { chain_id: u64, bundle: Option<Bundle>, action: Action }

Bundle {                                        // the hidden-asset bundle (since chain 14)
  anchor: Word8, nullifiers: [Word8; 4], commitments: [Word8; 4],
  fee: u64, burn_a: u64, burn_r: u64, burn_asset: u32, time: u32,
  envelopes: [Envelope; 4], proof: Vec<u8>,     // postcard(Proof) of the hidden-asset guest
  auth_commit: Word8, auth_proof: Vec<u8>,      // since chain 17: split authorisation's c and its auth proof
}
Envelope { kem_ct: Vec<u8>, to_receiver: Vec<u8>, to_sender: Vec<u8>, body: Vec<u8> }

Word8 آٹھ little-endian u32 الفاظ پر مشتمل ہے، جو 64 چھوٹے حروف والے ہیکس حروف کی صورت میں لکھے جاتے ہیں۔ وائر شکل bincode(Transaction) ہے، bincode کی طے شدہ ترتیبات کے ساتھ (مقررہ چوڑائی والے اعداد، 8 بائٹ کے لمبائی سابقے، u32 enum ٹیگ)، اور rand_sendTransaction اسے ہیکس کی صورت میں لیتا ہے۔ ٹرانزیکشن پر کوئی دستخط نہیں اور نہ ہی کوئی بھیجنے والے کا خانہ ہے: بنڈل اپنی اجازت اپنے ثبوتوں سے خود ثابت کرتا ہے (بنڈل ثبوت اور، chain 17 سے، اس کے ساتھ auth ثبوت)، اور جو ایکشن دستخط شدہ ہو وہ دستخط اپنے اندر ہی رکھتا ہے۔ ری پلے سے تحفظ بنڈلز کے لیے نلیفائر سیٹ ہے، دستخط شدہ اسٹیکنگ ایکشنز کے لیے رجسٹر میں ہر ویلیڈیٹر کا الگ نونس، TokenMint اور SetAuthority کے لیے ہر ٹوکن کا الگ mint_nonce، اور برج کے گورننس ایکشنز کے لیے اس کے pause_nonce اور list_nonce۔

ایک ٹرانزیکشن میں زیادہ سے زیادہ ایک بنڈل ہوتا ہے، اور ہر وہ ایکشن جو بنڈل کے بغیر والا نہیں، ٹھیک ایک بنڈل ساتھ رکھتا ہے۔ بنڈل کے سلاٹ 0–1 ایک نجی اثاثہ اور سلاٹ 2–3 RAND رکھتے ہیں، چنانچہ ایک ہی ثبوت ٹوکن منتقل کرتا ہے اور اس کی RAND فیس ادا کرتا ہے؛ پرانے ڈیزائن کا دو بنڈل والا برج برن ختم ہو چکا ہے: ایک برن ایک ہی بنڈل ہے (نوٹس)۔

rand والیٹ یہ سب کچھ randprotocol_client::wallet::{send, submit} کے ذریعے بناتا ہے: ان پٹس منتخب کرنا، اینکر حاصل کرنا، والیٹ کی اپنی ٹری کی نقل سے وٹنس نکالنا، آؤٹ پٹس بنانا اور چاروں لفافے مہر بند کرنا، ٹرانزیکشن کی بائنڈنگ لینا، بنڈل اور auth ثبوت تیار کرنا، بنڈل ثبوت کا شائع شدہ ڈائجسٹ جانچنا، اور جمع کرانا۔

ٹرانزیکشن بائنڈنگ

ٹرانزیکشن پر کوئی دستخط نہیں ہوتے، اور بنڈل کا ثبوت صرف بنڈل کے اپنے ڈائجسٹ کا پابند ہوتا ہے: اینکر، نلیفائرز، کمٹمنٹس، فیس، برن کے خانے، time۔ chain 13 تک کوئی چیز ثابت شدہ بنڈل کو اس ایکشن سے جس کے ساتھ وہ آیا، یا اس کے لفافوں سے نہیں جوڑتی تھی، اس لیے جو کوئی بھی ٹرانزیکشن دیکھتا وہ ثبوت کا ہر بائٹ برقرار رکھ کر باقی سب بدل سکتا تھا: BridgeBurn کی منزل، Bond کا ویلیڈیٹر، کوئی لفافہ۔ chain 14 سے ہر بنڈل ثبوت ٹرانزیکشن کی بائنڈنگ پر بنایا جاتا ہے اور اسی کے مقابل تصدیق کیا جاتا ہے:

binding(tx) = blake3("rand-tx-bind-1" || bincode(chain_id, bundle', action'))            chains 14 to 19
binding(tx) = blake3("rand-tx-bind-2" || bincode(genesis_hash, chain_id, bundle', action'))  chain 20
                                                                                  as 8 LE u32 words

جہاں ' کا مطلب ہے کہ بنڈل ثبوت کی ہر بائٹ سٹرنگ خالی ویکٹر سے بدل دی جاتی ہے: bundle.proof، chain 17 سے bundle.auth_proof، اور Aggregate کا proof۔ باقی سب کچھ اس کے اندر ہے: auth_commit، چاروں لفافے، برن کا ہر خانہ، منزل، ویلیڈیٹر، وصول کنندہ، دستخط، گارڈین کی تصدیق اور اس کے Dilithium2 مشترکہ دستخط، اور Call کا اپنا ثبوت۔ یہ آٹھ الفاظ ثبوت کے عوامی ان پٹ حصے میں جاتے ہیں، جس کا ڈائجسٹ H_PUB سرکٹ پہلے ہی پابند کرتا ہے، اس لیے اس اصلاح کے لیے گیسٹ یا سرکٹ میں کسی تبدیلی کی ضرورت نہیں پڑی؛ نوڈ Machine::verify_public(hc_bundle, binding, proof) چلاتا ہے اور ایسا بنڈل ثبوت مسترد کر دیتا ہے جو کوئی اور عوامی اونچائی ظاہر کرے (public height not the transaction binding's)۔ Transaction::binding وہ واحد فنکشن ہے جسے والیٹ ثبوت بنانے سے پہلے اور لیجر تصدیق سے پہلے بلاتا ہے۔ chain 17 سے auth ثبوت بھی انہی آٹھ الفاظ پر بنایا اور تصدیق کیا جاتا ہے، اس لیے اسے بھی کسی دوسری ٹرانزیکشن پر منتقل نہیں کیا جا سکتا۔

chain 20 جینیسس ہیش کو پابند کرتی ہے۔ chain 19 تک بائنڈنگ، اور بنڈل کے بغیر والے ایکشنز کے دستخط شدہ پیغامات، صرف chain id کا احاطہ کرتے تھے، چنانچہ ایک ہی chain id رکھنے والی دو چینیں (دوبارہ کٹی ہوئی چین، یا کوئی نجی نقل) ایک دوسرے کے ثبوت اور دستخط قبول کر لیتیں۔ chain 20 کا جینیسس binding_domain: 1 مقرر کرتا ہے (v0.6.8، audit v6 BIND-1؛ crates/randprotocol-core/src/types/binding.rs)۔ اس کے بعد جینیسس ہیش ہر پری امیج کے شروع میں ایک ورژن اوپر کے ٹیگ کے تحت آتا ہے: دونوں بائنڈنگز کے لیے rand-tx-bind-2 اور rand-call-bind-2، اور اسی طرح فاسٹ منٹ (rand-mint-3)، Unbond اور Withdraw (rand-unbond-2، rand-withdraw-2)، RPL منٹ اور اتھارٹی کے پیغامات (rand-rpl-mint-2، rand-rpl-authority-2)، ایگریگیٹر ایکشنز اور برج کے گورننس پیغامات کے لیے۔ ایسی چین پر ویلیڈیٹر کی رجسٹریشن ہمیشہ v2 پیغام ہوتی ہے (جینیسس، چین، ایڈریس، ادائیگی)۔ ایک چین کے لیے ثابت یا دستخط کی گئی کوئی چیز کسی دوسری چین پر تصدیق نہیں پاتی، خواہ اس کا chain id کچھ بھی ہو۔ بائنڈنگ کے الفاظ ایک عوامی ان پٹ ہیں، اس لیے کوئی گیسٹ یا تصدیق کنندہ کی کلید نہیں بدلی۔ v0.6.8 سے پرانا والیٹ اب بھی chain id والی شکل کے مقابل ثبوت بناتا ہے اور chain 20 پر مسترد کر دیا جاتا ہے۔ rand_getLimits اور rand_status binding_domain فراہم کرتے ہیں (chain 20 پر 1، خانہ نہ ہونے کی صورت میں 0)۔

جینیسس hardening_v6 کے تحت (chain 16 سے 20 تک) Call کا اپنا ثبوت بھی پابند کیا جاتا ہے، اسی ساخت کے ایک دوسرے ڈائجسٹ کے ذریعے جو اپنے الگ ڈومین کے تحت ہے، اور جس میں بنڈل کے ثبوتوں کے ساتھ ساتھ کال ثبوت بھی خالی کر دیا جاتا ہے:

call_binding(tx) = blake3("rand-call-bind-1" || bincode(chain_id, bundle', action''))   as 8 LE u32 words

chain 20 پر ٹیگ rand-call-bind-2 ہے اور جینیسس ہیش پری امیج کے شروع میں آتا ہے، جیسا کہ اوپر بیان ہوا۔ Invoke کا ثبوت بھی اسی طرح پابند کیا جاتا ہے، اور اس کی اعلان کردہ تبدیلی پری امیج میں رکھی جاتی ہے، چنانچہ ثبوت ٹھیک اسی حالتی تبدیلی، ادائیگیوں اور وصول کنندگان کا پابند ہوتا ہے جو ٹرانزیکشن میں موجود ہیں۔

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

کلائنٹ کے لیے اس کا نتیجہ: پوری ٹرانزیکشن — آؤٹ پٹس، لفافے، ایکشن — ثبوت بنانے سے پہلے تیار کریں۔ فورک سے پہلے بنا ہوا والیٹ خالی عوامی حصے کے مقابل ثبوت بناتا ہے اور مسترد کر دیا جاتا ہے۔ بنڈل کے بغیر والے ایکشنز کے پاس پابند کرنے کو کوئی ثبوت نہیں ہوتا اور وہ اپنے دستخطوں پر قائم ہیں۔ بائنڈنگ ٹرانزیکشن آئی ڈی نہیں ہے، جو بدستور وہی ہے۔

ٹرانزیکشن آئی ڈی

txid = blake3("rand-txid-3" || bincode(view))

جہاں view وہ ٹرانزیکشن ہے جس میں بنڈل کے proof بائٹس کی جگہ blake3(proof) (proof_hash) اور اس کے auth_proof بائٹس کی جگہ blake3(auth_proof) (auth_proof_hash، auth_commit کے بعد، جو جوں کا توں شامل ہوتا ہے) رکھ دیا جاتا ہے، اور باقی ہر خانہ لفظ بہ لفظ رہتا ہے۔ chain 16 تک ڈومین rand-txid-2 تھا، دونوں auth خانوں کے بغیر؛ chain 17 کے ساتھ ہر ٹرانزیکشن آئی ڈی بدل گئی۔ ثبوت کو اس کے ڈائجسٹ سے ہیش کرنا ہی وہ چیز ہے جو تراشے ہوئے بنڈل (بلاک ایگریگیشن، جو chain 20 پر فعال نہیں) کو اپنی خام شکل والی آئی ڈی برقرار رکھنے دیتی ہے؛ تراشا ہوا بنڈل اپنا auth ثبوت برقرار رکھتا ہے۔ بنڈل کے بغیر والی ٹرانزیکشن اپنے بائٹس جوں کے توں ہیش کرتی ہے۔ یہی آئی ڈی میم پول، رسیدوں اور ہر RPC تلاش کی کلید ہے۔

تمام ایکشنز

Action ایک bincode enum ہے، جس کے ٹیگ اعلان کی ترتیب میں ہیں:

MintAuthority = None | Key(PublicKey) | Bridge { backings: Vec<Backing> } | Program(Hash)
InitialMint   { amount: u64, recipient: ShieldedAddress, r: Word8, time: u32, envelope: Envelope }
PqSignature   { index: u8, signature: Vec<u8> }   // one guardian's Dilithium2 co-signature, by set index

چین 20 پر ٹیگ 0 تا 8، 14 تا 21، 28 اور 30 تا 33 قابلِ استعمال ہیں۔ اس کی جینیسس میں rules_v2 کے ساتھ ایک bridge سیکشن، ایک tokens سیکشن، staking.admission_by_vote (ٹیگ 28)، bridge.rotation (ٹیگ 30 تا 32) اور program_state (ٹیگ 33) موجود ہیں۔ وہاں ٹیگ 22 اور 23 مسترد کیے جاتے ہیں: bridge.rotation.needs_possession کے تحت روٹیشن کا …V2 شکل میں ہونا لازم ہے، جس میں ہر نئی کلید کا اپنا دستخط شامل ہوتا ہے۔ چین 19 پر، جس میں ان میں سے کوئی سیکشن نہیں تھا، ٹیگ 0 تا 8 اور 14 تا 23 قابلِ استعمال تھے (چین 14، جس میں rules_v2 نہیں تھا، 22 اور 23 کو مسترد کرتی تھی)۔ SlashEquivocation کے لیے staking.slashing سیکشن درکار ہے، اور چین 20 میں یہ سیکشن null ہے۔ ایگریگیشن کے پانچوں ایکشنز کے لیے aggregation سیکشن درکار ہے، جو چین 20 میں موجود نہیں (جب تک ایگریگیشن کی دوبارہ پیمائش نہ ہو جائے، بلڈ ایسی جینیسس پر چلنے سے انکار کر دیتا ہے جس میں یہ سیکشن موجود ہو)۔ نوڈ ان سب کو کسی بھی دوسری جانچ سے پہلے ابتدائی مرحلے پر ہی مسترد کر دیتا ہے، لیکن ان کے bincode ٹیگ بدستور مخصوص رہتے ہیں، اس لیے جو انکوڈر ٹیگ نمبر ہارڈ کوڈ کرے اسے انہیں بھی شمار کرنا ہوگا۔ ایگریگیشن کو پروفس میں آئندہ آنے والی خصوصیت کے طور پر بیان کیا گیا ہے۔ جینیسس ویسٹنگ کے چار ایکشنز (ٹیگ 24 تا 27، جو v0.5.11 سے بلڈ میں شامل ہیں) کے لیے vesting سیکشن درکار ہے، جو آج تک کسی چین میں نہیں رہا، چین 20 سمیت؛ اس سیکشن کے بغیر یہ داخلے کے مرحلے پر ہی مسترد کر دیے جاتے ہیں۔ ٹیگ 28 تا 33 v0.6.8 میں نئے ہیں اور سب سے آخر میں شامل کیے گئے ہیں، اس لیے ہر سابقہ چین کی تاریخ اب بھی ڈی کوڈ ہو جاتی ہے۔

RPL کے چار ایکشنز (ٹیگ 14 تا 17) ٹوکن رجسٹر کرتے ہیں، Key اختیار والے ٹوکن کی مزید مقدار منٹ کرتے ہیں، اس کا منٹ اختیار منتقل یا ترک کرتے ہیں، اور کسی ہولڈنگ کو جلاتے ہیں؛ جس RegisterToken میں Bridge یا Program اختیار درج ہو وہ مسترد کر دیا جاتا ہے۔ ٹوکن کی منتقلی کا کوئی الگ ایکشن نہیں ہے: ٹوکن کی منتقلی ایک None ہے، جو RAND کی ادائیگی سے ناقابلِ امتیاز ہے۔ دیکھیے RPL ٹوکنز۔ برج گورننس کے چار ایکشنز (ٹیگ 18 تا 21) یہ ہیں: منٹنگ کی معطلی، اس معطلی کا خاتمہ، اور جینیسس کے بعد کسی برجڈ ٹوکن یا کسی اضافی بیکنگ کی فہرست سازی۔ PauseMints پر جینیسس کی معطلی کلید دستخط کرتی ہے، جو صرف معطل کر سکتی ہے؛ باقی تین کے لیے Dilithium2 (PQ) گارڈینز کا کورم درکار ہے۔ BridgeAttest میں بھی، اپنے ECDSA کورم کے ساتھ، ایسا ہی کورم شامل ہوتا ہے۔ ٹیگ 22 اور 23، برج کے rules_v2 کے تحت، PQ گارڈینز کا مجموعہ یا معطلی کلید تبدیل کرتے ہیں، اور ہر ایک موجودہ مجموعے کے PQ کورم اور برج کے rotation_nonce کے تحت ہوتا ہے۔ ٹیگ 30 اور 31 یہی کام bridge.rotation کے تحت کرتے ہیں اور ساتھ ہی روٹیشن پیغام پر ہر نئی کلید کا اپنا Dilithium2 دستخط بھی رکھتے ہیں، جو اس بات کا ثبوت ہے کہ وہ کلید واقعی اس کے پاس ہے؛ چین 20 پر روٹیشن زیرِ التوا درج ہوتی ہے اور delay_secs، یعنی 86,400 s، کے بعد نافذ ہوتی ہے۔ CancelRotation (ٹیگ 32)، جس پر موجودہ معطلی کلید دستخط کرتی ہے، کسی زیرِ التوا روٹیشن کو نافذ ہونے سے پہلے منسوخ کر دیتا ہے۔ دیکھیے برج۔

AdmitValidator (ٹیگ 28) کسی نئی کلید کو شامل کرنے کے لیے ویلیڈیٹر مجموعے کا ووٹ ہے: ایسے ویلیڈیٹرز کے دستخط جن کے پاس اسٹیک کے دو تہائی سے زیادہ حصہ ہو، ایڈریس کی صعودی ترتیب میں۔ staking.admission_by_vote (چین 20) کے تحت ایسا Bond جو نیا ویلیڈیٹر رجسٹر کرے، اس وقت تک مسترد کیا جاتا ہے جب تک اس کا ایڈریس اس طریقے سے شامل نہ کیا گیا ہو (اسٹیکنگ)۔ Invoke (ٹیگ 33، RPL-2) ایسی کال ہے جس کا پروف پروگرام کی ایک اعلان کردہ اسٹیٹ transition کی ضمانت دیتا ہے: پڑھے اور لکھے گئے سیلز، بنڈل کے برن فیلڈز پروگرام کے والٹ میں کیا لاتے ہیں، اور وہ نوٹس جو والٹ ادا کرتا ہے یا پروگرام منٹ کرتا ہے۔ لیجر یہ ٹرانزیشن اس صورت میں لاگو کرتا ہے کہ ہر اعلان کردہ ریڈ اب بھی درست ہو اور دونوں پروفس کی تصدیق ہو جائے (پروگرامز)۔

Deploy اور Call عام شیلڈڈ ٹرانزیکشنز ہیں جن کا بنڈل صفر رقم کی اپنے ہی پتے پر منتقلی ہوتا ہے: اس کا مقصد کالر کے اپنے نوٹس سے کم از کم فیس ادا کرنا ہے، تاکہ چین کو کبھی معلوم نہ ہو کہ وہ نوٹس کس کے تھے۔ RAND پول سے صرف burn_r کے ذریعے نکلتا ہے — Bond کا اسٹیک، RegisterAggregator کا بانڈ، Invoke کا پروگرام والٹ میں جمع کرایا گیا حصہ — اور کوئی ٹوکن صرف burn_a کے ذریعے، جب burn_asset میں اسی کا نام ہو، کسی TokenBurn، BridgeBurn یا Invoke پر۔ کوئی بھی دوسرا ایکشن کچھ نہیں جلاتا، اور ایسا بنڈل جس میں burn_asset = 0 ہو اور burn_a صفر نہ ہو، ہر جگہ مسترد کر دیا جاتا ہے۔

داخلے کی ترتیب

Ledger::validate_inner مہنگی جانچوں سے پہلے سستی جانچیں کرتا ہے، اسی ترتیب سے؛ میم پول گاسپ کرنے سے پہلے یہی جانچ چلاتا ہے، اس لیے غلط ٹرانزیکشن ایک ہی بار، نیٹ ورک کے کنارے پر، مسترد ہو جاتی ہے۔

1. حجم کی حدیں — پوری ٹرانزیکشن ≤ چین کا max_block_bytes؛ بنڈل کے چاروں لفافوں میں سے ہر ایک، اور کارروائی کے ساتھ آنے والا کوئی بھی نوٹ لفافہ، ٹھیک جینیسس کے envelope_bytes کے برابر (چین 20 پر 1,860؛ اس فیلڈ کے بغیر چین پر زیادہ سے زیادہ 2,048 بائٹس)؛ بنڈل ثبوت، اجازتی ثبوت اور کال ثبوت میں سے ہر ایک ≤ max_proof_bytes (بطورِ طے شدہ 2 MiB، چین 20 کے جینیسس میں 4 MiB؛ چین 13 تا 16 پر یہ 8 MiB تھا)؛ پروگرام ≤ چین کی پروگرام حد (بطورِ طے شدہ 4,096 الفاظ، چین 20 کے جینیسس میں 65,535)؛ کال لفافہ ≤ max_call_envelope_bytes (بطورِ طے شدہ 18,432 بائٹس، چین 20 پر 65,536)؛ تصدیق نامہ ≤ 16 KiB۔ مہر بند (تراشیدہ) نشان والی شکل کا بنڈل ثبوت، مہر بند شکل کی ہم وقت سازی کے علاوہ، یہیں رد کر دیا جاتا ہے (PrunedFormOutsideSync)، ثبوت پر کوئی بھی کام ہونے سے پہلے۔
2. چین id مطابقت رکھتی ہے۔
3. ساخت اور کم از کم فیس — بنڈل کے بغیر کارروائی کوئی بنڈل نہیں رکھتی اور باقی ہر کارروائی کو ٹھیک ایک بنڈل رکھنا لازم ہے؛ check_burn_shape طے کرتا ہے کہ کارروائی جلانے کے تین فیلڈز میں سے کون سے مقرر کر سکتی ہے: TokenBurn یا BridgeBurn اپنا asset اور amount، burn_asset اور burn_a کے ذریعے جلاتی ہے، Bond یا RegisterAggregator اپنی رقم burn_r کے ذریعے جلاتی ہے، اور باقی ہر کارروائی کچھ نہیں جلاتی؛ fee ≥ fee_floor(action)۔ جس چین میں gas حصہ ہو (چین 20) وہاں اس مرحلے پر Call یا Invoke کی کم از کم فیس 1 کی اعلان کردہ حد پر گیس کا قاعدہ ہے، یعنی اس کے ثبوت اور ان پٹ لفافے پر BUNDLE_BASE + gas_price + byte_price × ⌈bytes / 1024⌉، جو کسی بھی تصدیق سے پہلے معلوم ہوتے ہیں۔
4. اینکر — چین 20 پر، جس کا جینیسس proof_window_blocks: 1024 مقرر کرتا ہے (v0.6.8)، بلاک کے اختتام کی آخری 1,024 جڑوں میں سے ایک؛ اس فیلڈ کے بغیر چین پر، جیسا کہ چین 19 تک تھا، آخری 256 میں سے ایک۔
5. وقت — چین 20 پر [height − 1024, height] کے اندر؛ اس فیلڈ کے بغیر [height − 256, height]۔ جینیسس کی یہی ایک قدر دونوں دائرے مقرر کرتی ہے۔
6. نلیفائرز اور کمٹمنٹس — چاروں نلیفائرز ایک دوسرے سے مختلف ہیں اور کوئی خرچ شدہ نہیں؛ چاروں کمٹمنٹس ایک دوسرے سے مختلف ہیں اور کوئی پہلے سے پتّا (leaf) نہیں۔
7. کارروائی کی جانچ — فاسیٹ فعال ہے، اجرا حد کے اندر اور توثیق کنندہ کا دستخط شدہ ہے، اور چین 20 پر ایسے وصول کنندہ کا نام لیتا ہے جو جینیسس کی staking.faucet_recipients اجازت فہرست میں ہو، epoch کے faucet_budget_per_epoch میں سما جاتا ہے اور جینیسس کی staking.faucet_minters فہرست کے کسی توثیق کنندہ کا دستخط شدہ ہے (چین 16 سے یہ صحت کا قاعدہ ہے)؛ 2⁶³ یا اس سے زائد کا اجرا یا جمع ہر چین پر رد ہوتا ہے؛ پروگرام ڈی کوڈ ہوتا ہے؛ پروگرام موجود ہے؛ اسٹیکنگ کے قواعد (رجسٹریشن ٹھیک اسی وقت موجود ہو جب توثیق کنندہ نامعلوم ہو، nonce، دستخط، کافی اسٹیک)؛ BridgeAttest اور BridgeBurn کے لیے اور معطلی و فہرست سازی کی کارروائیوں کے لیے برج کے اپنے قواعد؛ RPL کی چار کارروائیوں کے لیے اس کے قواعد، رجسٹریشن فیس سمیت؛ چین 20 پر داخلے کی رائے شماری کا کورم، اور Invoke کے لیے تبدیلی کی ساخت، محفوظ سیلز کے مقابل اعلان کردہ ریڈز، ہر ادائیگی کے لیے والٹ کی ضمانت اور سیل فیس۔ یہ سب بنڈل کے ثبوت سے پہلے چلتا ہے، اس لیے جو ٹرانزیکشن لاگو نہیں ہو سکتی اس پر STARK کی تصدیق کی کوئی لاگت نہیں آتی۔ hardening_v6 کے تحت (چین 16 تا 20) یہاں دو مزید انکار ہیں: ایسے پروگرام کا Deploy جسے کوئی کال سنبھال نہ سکے (ProgramUncallable)، اور ایسا بنڈل یا کال ثبوت جس کے ہیڈر یا ٹرانسکرپٹ میں ایسا فیلڈ ہو جو دیانت دار ثابت کنندہ نہ لکھتا (non-canonical proof: …)، جو دونوں میں سے کسی ثبوت کی تصدیق سے پہلے رد ہو جاتا ہے۔ v0.6.8 سے، جس ثبوت کا ہیڈر سب سے بلند جدول کی حد سے زیادہ درجہ ظاہر کرے وہ اسی فیصلے کے تحت سب سے پہلے رد ہوتا ہے (audit v6 ZKV-4)، جانچ کے اس پر چلنے سے پہلے۔
8. بنڈل ڈائجسٹ — منقسم اجازت دہی والی چین پر (چین 17 سے ہر چین) پہلے اجازتی فیلڈز جانچے جاتے ہیں: اجازتی ثبوت کے بغیر بنڈل رد ہوتا ہے، اجازتی ثبوت جو c شائع کرتا ہے (پڑھا گیا، ابھی تصدیق شدہ نہیں) اسے auth_commit کے برابر ہونا لازم ہے، اور چین 20 پر اجازتی ثبوت کو ٹھیک 1,279 کا GAS_LIMIT ظاہر کرنا لازم ہے۔ پھر لیجر بنڈل کے شائع شدہ فیلڈز کا ڈائجسٹ دوبارہ حساب کرتا ہے، جن میں auth_commit بھی شامل ہے، اور اسے ثبوت کے شائع کردہ ڈائجسٹ کے برابر ہونا لازم ہے۔ چین 20 پر بنڈل ثبوت کو بھی ٹھیک جینیسس کے bundle_gas_limit، یعنی 20,479، کا GAS_LIMIT ظاہر کرنا لازم ہے۔
9. بنڈل ثبوت — جینیسس میں مقرر hc_bundle اور ٹرانزیکشن کی بندش کے مقابل Machine::verify_public۔ منقسم اجازت دہی والی چین پر اس کے بعد اجازتی ثبوت کی تصدیق ہوتی ہے، جینیسس میں مقرر hc_auth اور اسی بندش کے مقابل۔
10. کال ثبوت اور اس کے درجے کی فیس — Call یا Invoke کے لیے پہلے ثبوت کا ہیڈر مقرر کیا جاتا ہے (درجہ زیادہ سے زیادہ 14، keccak جدول زیادہ سے زیادہ 2¹²، sha256 جدول زیادہ سے زیادہ 2¹³، تعینات شدہ پروگرام کی بلندی، hardening_v6 کے تحت کم از کم 2⁷ قطاریں، اور چین 20 پر اعلان کردہ GAS_LIMIT جو ہیڈر کی حد gas_max سے زیادہ نہ ہو)، پھر پروگرام کے code_hash اور، hardening_v6 کے تحت، ٹرانزیکشن کی کال بندش کے مقابل کال کا STARK۔ فیس سب سے آخر میں جانچی جاتی ہے، کیونکہ وہ ثبوت کے ڈی کوڈ ہونے کے بعد ہی معلوم ہو سکتی ہے: چین 20 پر رائج قیمتوں پر fee ≥ BUNDLE_BASE + gas_price × GAS_LIMIT + byte_price × ⌈bytes / 1024⌉، اور Invoke کے لیے ہر بنائے گئے سیل پر cell_fee مزید (فیسیں)؛ gas حصے کے بغیر چین پر fee ≥ BUNDLE_BASE + call_fee(tier)۔

خرابیاں rand_sendTransaction سے کوڈ -32000 کے ساتھ وجہ سمیت واپس آتی ہیں: nullifier already spent، anchor is not one of the last 1024 roots (proof_window_blocks کے بغیر چین پر 256)، time 12 is outside [476, 1500]، fee 1000000 below minimum 2000000، the bundle's digest is not what its proof published، invalid bundle proof: …، unknown program …، already in mempool، conflicts with a pending transaction over <nullifier>، faucet is disabled on this chain، اور چین 14 سے the bundle burns asset 2 on an action that burns no token، a burn of 5 is not allowed on this action، the bundle burns 399, not the 400 the action declares، wrong mint nonce: expected 1, got 0، wrong token index: expected 3, got 2، چین 17 سے this chain requires an auth proof on every bundle (genesis hc_auth) اور the auth proof publishes a different commitment than the bundle's auth_commit، اور چین 20 پر envelope is 1348 bytes, this chain requires exactly 1860 اور bundle proof declares gas limit …, this chain requires exactly 20479۔ قبولیت کمٹمنٹ نہیں ہے: rand_getTransaction کو اس وقت تک پول کریں جب تک وہ بلاک واپس نہ کرے۔

جس بلاک میں کوئی بھی غیر درست ٹرانزیکشن ہو وہ بلاک غیر درست ہے۔ میم پول ہر زیرِ التوا نلیفائر اور کمٹمنٹ کی فہرست رکھتا ہے اور تصادم کو فوراً رد کر دیتا ہے، اس لیے ایک ہی نوٹ خرچ کرنے والے دو بنڈل کبھی ایک بلاک میں شامل نہیں ہوتے۔

حجم

پہلی چھ قطاریں چین 18 سے رائج انکوڈنگ ہیں: میمو فیلڈ نے ہر لفافے میں 512 بائٹس کا اضافہ کیا، اور منقسم اجازت دہی نے اجازتی ثبوت کے اپنے بائٹس سے پہلے بنڈل میں 40 بائٹس کا اضافہ کیا۔ چنانچہ چین 18 سے، چین 20 سمیت، ایک شیلڈ شدہ منتقلی نیٹ ورک پر تقریباً 2.88 MB کی ہوتی ہے، جو تقریباً سب کی سب ثبوت ہے، خواہ وہ کوئی بھی اثاثہ منتقل کرے: تقریباً 1.5 MB بنڈل ثبوت اور 1.37 MB اجازتی ثبوت۔ چین 15 تک، ایک ثبوت کے ساتھ، یہ تقریباً 1.43 MB تھی۔ بلاکس کی حد 2,000 ٹرانزیکشنز (MAX_BLOCK_TXS) اور ٹرانزیکشن بائٹس میں چین کا max_block_bytes ہے، اور دونوں اتفاقِ رائے کے قواعد ہیں: بطورِ طے شدہ 4 MiB (MAX_BLOCK_BYTES)، جس میں ایسی ایک منتقلی سمائے گی، اور چین 20 کے جینیسس میں 20 MiB، جس میں سات کی گنجائش ہے۔ جس جینیسس میں hc_auth ہو اسے max_block_bytes کو کم از کم max_proof_bytes کے تین گنا جمع 1 MiB پر مقرر کرنا لازم ہے، کیونکہ ایک ٹرانزیکشن تین ثبوت (بنڈل، اجازت، کال) رکھ سکتی ہے، اس لیے وہاں 4 MiB کی طے شدہ قدر رد ہو جاتی ہے۔ بلاک کی سطح پر یکجائی وہ حل ہے جو قطار میں ہے؛ دیکھیں ثبوت۔

ٹرانزیکشن واپس پڑھنا

rand_getTransaction(hash) اس وقت تک null واپس کرتا ہے جب تک ٹرانزیکشن کمٹ نہ ہو جائے، پھر اس کا بلاک میں مقام اور صرف عوامی فیلڈز:

{
  "height": 192, "index": 0, "block_hash": "63f6…08",
  "tx": {
    "hash": "4f2c…e7", "chain_id": 20,
    "bundle": {
      "anchor": "6b1d…c4",
      "nullifiers": ["8c04…d1", "5e77…20", "03aa…6f", "e19b…42"],
      "commitments": ["2a9f…07", "b310…88", "77c1…0e", "5d20…b3"],
      "fee": "1000000", "burn_a": "0", "burn_r": "0", "burn_asset": 0, "time": 5,
      "proof_len": 1497544, "envelope_len": [1860, 1860, 1860, 1860],
      "auth_commit": "0bab…e8a1", "auth_proof_bytes": 1370827
    },
    "action": { "kind": "none" }
  }
}

ٹرانسفر میں نہ کوئی from ہے، نہ to، نہ nonce، نہ رقم اور نہ کوئی asset فیلڈ، اور ذخیرہ شدہ بلاک میں بھی ان میں سے کچھ نہیں ہوتا: نوڈ کے پاس چھپانے کو مزید کچھ باقی نہیں۔ auth_commit اور auth_proof_bytes (auth ثبوت کی لمبائی) chain 17 سے موجود ہیں۔ بنڈل میں ہمیشہ چار خانے ہوتے ہیں، فرضی خانوں سمیت، اور RAND کا ٹرانسفر اور کسی بھی RPL ٹوکن کا ٹرانسفر دونوں "kind": "none" ہوتے ہیں۔ chain 14 سے ہر u64 رقم ایک اعشاری سٹرنگ ہے (fee، burn_a، burn_r، کسی ایکشن کی amount)؛ اشاریے، nonces، بلندیاں اور لمبائیاں JSON اعداد ہی رہتی ہیں۔ دیگر اقسام کے ایکشن اپنی عوامی فیلڈز ظاہر کرتے ہیں — mint، deploy، call، bond، unbond، withdraw، bridge_attest، bridge_burn، register_token، token_mint، set_authority، token_burn، pause_mints، unpause_mints، register_bridged_token، list_backing، rotate_pq_guardians، rotate_pause_key، ویسٹنگ کی چار اقسام claim_vested، revoke_vesting، bond_vested، unbond_vested، اور v0.6.8 سے admit_validator، slash_equivocation، rotate_pq_guardians_v2، rotate_pause_key_v2، cancel_rotation اور invoke — جیسا کہ JSON-RPC حوالہ میں درج ہے۔