اس صفحے سے چین کے ساتھ باہمی عمل کے لیے درست لائبریری منتخب کریں، کسی پیرامیٹر کا اس قدر سے موازنہ کریں جو نوڈ نافذ کرتا ہے، اور کسی id یا کمٹمنٹ کا خود دوبارہ حساب لگائیں۔ یہاں دی گئی ہر قدر وہی ہے جس پر کوڈ چین 20 (fullnode v0.6.8) پر چلتا ہے۔
بنیادی عناصر اور ان کا استعمال
| بنیادی عنصر | پیرامیٹرز | استعمال |
|---|---|---|
| Dilithium2 | 1,312 بائٹ عوامی کلید، 2,420 بائٹ دستخط؛ کلیدی جوڑے 32 بائٹ سیڈ سے اخذ کیے جاتے ہیں | توثیق کاروں کے ووٹ اور بلاک کی تجاویز؛ فاسیٹ کے اجرا؛ Unbond، Withdraw اور کسی توثیق کار کی Registration؛ کسی AdmitValidator کے ووٹ (چین 20)؛ یکجا کنندہ کے اقدامات؛ کسی RPL ٹوکن کا Key اجرائی اختیار (TokenMint، SetAuthority)؛ برج کے پوسٹ کوانٹم نگہبانوں کے مشترکہ دستخط، اس کی توقف کلید اور، چین 20 پر، کسی گردش میں نئی کلیدوں کے ملکیتی ثبوت (نیچے) |
| ML-KEM-768 | 1,184 بائٹ انکیپسولیشن کلید، 1,088 بائٹ سائفر ٹیکسٹ | نوٹ لفافے کی فی ٹرانزیکشن کلید کو وصول کنندہ کے پتے کے لیے مہر بند کرنا؛ کال ان پٹ لفافے کو کسی آڈیٹر کے لیے مہر بند کرنا؛ ثبوت سازی کے کام کو جوڑے گئے ثابت کنندہ کے لیے مہر بند کرنا |
| ChaCha20-Poly1305 | 32 بائٹ کلید، شروع میں لگا ہوا بے ترتیب 12 بائٹ نانس، 16 بائٹ ٹیگ | لفافے کا ہر حصہ: نوٹوں کے متن، لپیٹی ہوئی ٹرانزیکشن کلیدیں، کال ان پٹ کے ٹرانسکرپٹ؛ جوڑے گئے ثابت کنندہ کے کام اور جوابات |
| BLAKE3 | 32 بائٹ آؤٹ پٹ، ہمیشہ شروع میں ایک ڈومین اسٹرنگ کے ساتھ | پتے، ٹرانزیکشن ids، ٹرانزیکشن بائنڈنگ اور کال بائنڈنگ، پروگرام ids، ٹوکن اثاثہ ids، اسٹیٹ روٹ اور اس کے Merkle درخت، p2p شناخت، دستخطی پیغامات، برج اثاثہ ids، برج ڈپازٹ کی بلائنڈنگ اور برج فیس نوٹوں کی بلائنڈنگز |
| Poseidon2 (Goldilocks پر) | چوڑائی 8، شرح 4، گنجائش 4، بغیر پیڈنگ کا اوور رائٹ اسپنج؛ پیغام کے عناصر 32 بٹ الفاظ ہیں؛ چین 15 کے اجرا سے 86 راؤنڈ مستقلات نوڈ کے سورس (poseidon2_constants.rs) میں ایک لفظی جدول کی صورت میں ہیں، وہی قدریں جو اس سے پہلے سیڈ شدہ قرعہ اندازی سے حاصل ہوتی تھیں | ثبوت کے اندر سب کچھ: کلیدیں، نوٹ کمٹمنٹس، نلیفائرز، کمٹمنٹ درخت، پروگرام ڈائجسٹ hc، ان پٹ کمٹمنٹس H_IN اور H_PUB، بنڈل ڈائجسٹ، اجازت کمٹمنٹ |
| secp256k1 ECDSA + keccak256 | low-s دستخط، Ethereum طرز کے 20 بائٹ نگہبان پتے، mu = keccak256(keccak256(body)) | برج نگہبانوں کی شہادتیں، تاکہ وہی کلید EVM کنٹریکٹس، Solana پروگرام اور Rand پر کام کرے؛ Rand پر ہر شہادت کے لیے نیچے بیان کردہ Dilithium2 کورم بھی لازم ہے |
| bech32m (BIP-350) | انسانی قابلِ مطالعہ حصہ rpl، 32 بائٹ پے لوڈ، 52 ڈیٹا حروف + 6 چیک سم حروف = 62 | کسی RPL ٹوکن کے اثاثہ id کی متنی شکل rpl1… |
| Plonky3 بیچ STARK | Goldilocks p = 2⁶⁴ − 2³² + 1، پوشیدہ رکھنے والا FRI، بلو اپ 8، فولڈنگ آریٹی 8، 80 استفسارات، 20 پروف آف ورک بٹس | ہر بنڈل ثبوت، اجازت ثبوت اور کال ثبوت؛ بنڈل ثبوت اور اس کا اجازت ثبوت اپنی ٹرانزیکشن کے آٹھ بائنڈنگ الفاظ کو اپنے عوامی ان پٹ حصے کے طور پر ساتھ رکھتے ہیں |
وائٹ پیپر کے ہدفی پیرامیٹرز بعض جگہوں پر ان پیرامیٹرز سے مختلف ہیں جن پر نفاذ چلتا ہے (مثلاً پیپر کا 384 بٹ ٹرانسکرپٹ ہیش، بمقابلہ zkVM کا Poseidon2 ٹرانسکرپٹ)۔ یہ صفحات کوڈ کو بیان کرتے ہیں۔
برج پر پوسٹ کوانٹم مشترکہ دستخط
برج کے نگہبانوں کی شہادتیں secp256k1 ECDSA پر مبنی ہیں، جنہیں کوانٹم مخالف جعل کر سکتا ہے۔ چین 14 سے ہر BridgeAttest کے ساتھ، خواہ وہ ڈپازٹ ہو یا نگہبان سیٹ کی گردش، انہی نگہبانوں کے اسی ڈائجسٹ پر Dilithium2 دستخطوں کا کورم بھی لازم ہے:
M = "rand-bridge-pq-cosign-1" || rand_chain_id (u64 BE) || mu // 63 bytes, deterministic signingجہاں mu = keccak256(keccak256(body)) وہ ڈائجسٹ ہے جس پر ECDSA کورم دستخط کرتا ہے۔ M میں شامل Rand چین id کسی testnet مشترکہ دستخط کو کسی دوسری Rand چین پر تصدیق پانے سے روکتی ہے، خواہ نگہبان کلیدیں دوبارہ استعمال ہوئی ہوں۔ M صرف چین id کو باندھتا ہے، چین 20 پر بھی: یہ وہ واحد دستخط شدہ پیغام ہے جسے binding_domain نے جینیسس ہیش کے پیچھے منتقل نہیں کیا، کیونکہ اس پر دستخط کرنے والے نگہبان ڈیمن ایک دوسری ریپوزیٹری میں ہیں۔ اسی چین id اور اسی نگہبان سیٹ والی کسی چین کی نقل اس کے ڈپازٹس کے مشترکہ دستخط قبول کر لے گی؛ نگہبان سیٹ کا اشاریہ M میں شامل نہیں، اس لیے مشترکہ دستخط ECDSA سیٹ کی گردش کے بعد بھی کارآمد رہتا ہے۔ اقدام کا pq_signatures فیلڈ PqSignature { index: u8, signature } کی فہرست ہے، جس کی جانچ سستی سے مہنگی کی ترتیب میں ہوتی ہے: quorum(n) ≤ len ≤ n (PqNoQuorum)، اشاریے سختی سے بڑھتے ہوئے (PqIndexOrder)، ہر اشاریہ n سے کم (PqIndexOutOfRange)، ہر دستخط ٹھیک 2,420 بائٹ (PqBadSignatureLength)، اور آخر میں ہر دستخط کی pq_guardians[index] کے تحت تصدیق (PqBadSignature)۔ PQ دستخط کنندگان کا وہی ہونا ضروری نہیں جو ECDSA دستخط کنندگان ہیں؛ ہر کورم الگ گنا جاتا ہے۔ یہ فیلڈ ٹرانزیکشن بائنڈنگ کے اندر ہے، اس لیے کسی نقل پر اسے نہ ہٹایا جا سکتا ہے نہ بدلا جا سکتا ہے۔
PQ سیٹ جینیسس کا bridge.pq_guardians ہے: چین 20 پر آٹھ 1,312 بائٹ کلیدیں، جیسا کہ چین 15 تا 19 پر، جو اشاریہ وار جینیسس ECDSA سیٹ، یعنی نگہبان سیٹ 1، سے ہم آہنگ ہیں (چین 14 پر چھ تھیں، سیٹ 0 سے ہم آہنگ)۔ ECDSA نگہبان سیٹ کی گردش اسے کبھی نہیں بدلتی۔ چین 14 پر یہ چین کی پوری عمر کے لیے طے شدہ تھا؛ چین 15 سے جینیسس میں برج کا rules_v2 گروپ شامل ہے، جس کے تحت ایک PQ کورم پورا PQ سیٹ (RotatePqGuardians) یا توقف کلید (RotatePauseKey) بدل سکتا ہے، ہر ایک برج کے rotation_nonce کے تحت۔ چین 20 کا جینیسس bridge.rotation کا اضافہ کرتا ہے: گردش لازماً V2 اقدام ہو، جس میں ہر نئی کلید کا اپنا Dilithium2 دستخط اسی پیغام پر موجود ہو (ملکیت کا ثبوت)، اور یہ بلاک میں شامل ہونے کے ایک دن بعد نافذ ہوتی ہے، الا یہ کہ موجودہ توقف کلید اسے منسوخ کر دے (برج)۔ rand_getBridgeState کلیدیں فراہم کرتا ہے، اور ڈی کوڈ شدہ bridge_attest میں pq_signers درج ہوتے ہیں، یعنی دستخط کرنے والوں کے اشاریے۔ یہی PQ کورم برج کے انتظامی پیغامات کی اجازت دیتا ہے، جن میں سے ہر ایک کی ترتیب مقررہ اور بگ اینڈین ہے اور اس میں چین id اور ایک نانس شامل ہوتے ہیں۔ چین 20 پر (جینیسس binding_domain: 1) ہر ڈومین کا ورژن ہندسہ 2 ہے اور 32 بائٹ جینیسس ہیش ڈومین اور چین id کے درمیان آتا ہے؛ چین 14 تا 19 -1 والی شکلیں استعمال کرتی ہیں:
| پیغام | ڈومین (چین 14–19 / چین 20) | دستخط کنندہ |
|---|---|---|
M_pause | rand-bridge-pause-1 / -2 | جینیسس کی واحد توقف کلید (Dilithium2)، جو روک سکتی ہے مگر کبھی بحال نہیں کر سکتی |
M_unpause | rand-bridge-pq-unpause-1 / -2 | PQ نگہبانوں کا کورم |
M_list | rand-bridge-pq-list-1 / -2 | PQ نگہبانوں کا کورم (ListBacking) |
M_register | rand-bridge-pq-register-1 / -2 | PQ نگہبانوں کا کورم (RegisterBridgedToken) |
M_rotate_pq | rand-bridge-pq-rotate-pq-1 / -2 | موجودہ PQ سیٹ کا کورم (RotatePqGuardians، rules_v2 والی چینز)؛ چین 20 پر ہر نئی کلید بھی، اپنے ملکیتی ثبوت کے طور پر |
M_rotate_pause | rand-bridge-pq-rotate-pause-1 / -2 | موجودہ PQ سیٹ کا کورم (RotatePauseKey، rules_v2 والی چینز)؛ چین 20 پر نئی کلید بھی |
M_cancel | rand-bridge-cancel-rotation-1 / -2، آخر میں ایک kind بائٹ کے ساتھ | موجودہ توقف کلید (CancelRotation، bridge.rotation والی چینز: چین 20) |
پروڈکشن میں STARK
zkVM قیود کے سیٹ 8 پر ہے: نو لازمی جدول (program، cpu، memory، alu، range، nibble، poseidon2، input، public)، نیز ایک keccak اور ایک sha256 جدول جو ثبوت صرف اسی صورت میں ساتھ رکھتا ہے جب اس کے گیسٹ نے متعلقہ سسٹم کال استعمال کی ہو۔ یہ سب سترہ بسوں سے جڑے ہیں اور ایک بیچ STARK کے طور پر ثابت کیے جاتے ہیں۔ قیود کے سیٹ 7 سے ہر اعلان شدہ جدول میں کم از کم 2⁷ قطاریں ہیں، اور ہر جدول کا LogUp ٹرمینل سترہویں بس، BLIND، کے ذریعے پوشیدہ کیا جاتا ہے۔ ثبوت کا عوامی انٹرفیس 35 فیلڈ عناصر (pv::NUM) پر مشتمل ہے: داخلی pc، درجہ، آٹھ آؤٹ پٹ الفاظ، پروگرام ڈائجسٹ hc (8 الفاظ)، نمک شدہ نجی ان پٹ کمٹمنٹ H_IN (8)، بغیر نمک کے عوامی حصے کا ڈائجسٹ H_PUB (8) اور، قیود کے سیٹ 8 سے، اعلان شدہ گیس حد GAS_LIMIT۔
| پیرامیٹر | پروڈکشن | تبصرہ |
|---|---|---|
| FRI استفسارات | 80 | قیود کے سیٹ 3 اور 4 میں 27 استفسارات والی نئی ترتیب 2026-09-12 کے آڈٹ کے بعد واپس لے لی گئی، کیونکہ اس سے صرف ~42 ثابت شدہ بٹس رہ گئے تھے |
| بلو اپ | 8 (log_blowup = 3) | ہر جدول کی قیود کی زیادہ سے زیادہ ڈگری 8 کی حد سے نیچے رکھی گئی ہے |
| فولڈنگ آریٹی | 8 | |
| پروف آف ورک بٹس | 20 | |
| درستی | 3·80 + 20 = 260 بٹس قیاسی (ethSTARK)؛ قربتی خلا کے تحت تقریباً 86 بٹس ثابت شدہ | |
| صفر علم | شماریاتی: LDE اور FRI بیچ کثیر رکنی کو بے ترتیب بنایا جاتا ہے، اس لیے ایک ہی رن کے دو ثبوت مختلف ہوتے ہیں | قیود کے سیٹ 7 سے ہر اعلان شدہ جدول کم از کم 2⁷ قطاروں کا ہے، جو ثبوت میں کھولے جانے والے 82 نقاط سے زیادہ ہے، اور LogUp ٹرمینلز پوشیدہ کیے جاتے ہیں |
| درجے | 10، 12، 14، 16، 18، 20 | ثبوت درجہ ظاہر کرتا ہے، سائیکلوں کی تعداد کبھی نہیں؛ fullnode v0.5.6 سے درجہ 14 سے اوپر کا کال ثبوت مسترد کیا جاتا ہے (CallTierTooHigh)، بنڈل ثبوت درجہ 14 پر اور اجازت ثبوت درجہ 10 پر مقرر ہے |
| ثبوت کی حد | جینیسس کا max_proof_bytes: چین 17 تا 20 پر 4 MiB (4,194,304)؛ چین 13 تا 16 پر 8 MiB؛ جس جینیسس میں یہ موجود نہ ہو، جیسے چین 12، اس پر 2 MiB (MAX_PROOF_BYTES) | 2 MiB ہیش جدول کے بغیر ہر اس ثبوت سے زیادہ ہے جو تعینات شدہ گیسٹ تیار کر سکتے ہیں، اور keccak جدول والے ثبوت سے کم؛ 4 MiB دونوں کو قبول کرتا ہے |
| گیس | ہر cpu قطار پر 1؛ ہر Poseidon2 جذب قطار پر 3؛ ہر SHA256 قطار پر 64؛ ہر KECCAK قطار پر 192 | cpu جدول کے GAS کالم میں جمع ہوتی ہے اور ثابت کیا جاتا ہے کہ یہ زیادہ سے زیادہ GAS_LIMIT ہے؛ تصدیق کنندہ gas_max(t, k, s) = (2ᵗ − 1) + 2ᵗ⁻² + 191·(2ᵏ/32) + 63·(2ˢ/64) سے زیادہ حد مسترد کرتا ہے، جو ہیش سے خالی درجہ 10 ہیڈر کے لیے 1,279 اور درجہ 14 والے ہیڈر کے لیے 20,479 ہے |
قیود کے مجموعہ 6 پر ناپے گئے سائز (Apple Silicon، ریلیز بلڈ): keccak سے پاک ایک پروڈکشن ثبوت درجہ 10 پر 1,298,729 بائٹ اور درجہ 12 پر 1,359,978 بائٹ کا تھا؛ keccak والا درجہ 10 کا ثبوت 3,198,430 بائٹ کا تھا، جو 2 MiB کی طے شدہ حد سے زیادہ اور چین 13 تا 15 کی 8 MiB حد سے کم تھا۔ متروک 2-in-2-out بنڈل گیسٹ کا درجہ 14 کا ثبوت چین 8 پر 1,321,773 بائٹ اور چین 13 پر 1,418,406 سے 1,420,423 بائٹ ناپا گیا۔ چین 14 کا 4-in-4-out پوشیدہ اثاثہ بنڈل گیسٹ کسی بھی ہیش جدول کے بغیر درجہ 14 پر رہتا ہے، اور اس کے ثبوت چین 14 پر 1,422,116 اور 1,423,170 بائٹ ناپے گئے (2026-09-20)، اور چین 15 نے یہی گیسٹ مقرر کیا (hc_bundle میں کوئی تبدیلی نہیں)؛ وہاں ایک بنڈل ثبوت نے public_log_height 4 کا اعلان کیا، جو آٹھ بائنڈنگ الفاظ کی اونچائی ہے، اور نوڈ نے تصدیقی کلید بنانے سے پہلے ہی کسی اور قدر کو رد کر دیا۔ چین 13 پر 2026-09-19 کو بنایا گیا keccak والا ERC-20 approve کال ثبوت (درجہ 16) 3,412,405 بائٹ کا ہے؛ fullnode v0.5.6 کے بعد سے ہر چین درجہ 16 پر اس کال کو رد کرتی ہے۔
قیود کے مجموعہ 7 کے اخفائی کالم اور جدولوں کی کم از کم حدیں ہیش سے پاک ثبوت میں تقریباً 5% کا اضافہ کرتی ہیں: fullnode کی 2026-09-28 کی پیمائش کے مطابق fib درجہ 10 پر 1,367,688 بائٹ اور درجہ 12 پر 1,424,299 بائٹ ہے، keccak والا درجہ 10 کا ثبوت 3,283,898، اور درجہ 14 کا پوشیدہ اثاثہ بنڈل ثبوت 1,498,821 (گیسٹ v1) اور 1,497,156 (گیسٹ v2)۔ تب سے ایک بنڈل ثبوت public_log_height 7 کا اعلان کرتا ہے۔ قیود کا مجموعہ 8 1% سے کم اضافہ کرتا ہے۔ چین 18 پر 2026-09-30 کی پیمائش (Apple Silicon): 1,364,940 سے 1,375,371 بائٹ کے اجازتی ثبوت (درجہ 10)، 1,494,151 سے 1,504,260 بائٹ کے بنڈل ثبوت (درجہ 14، گیسٹ v3)، اور کال ثبوت: ہیش جدول کے بغیر درجہ 14 پر 1,498,589 بائٹ، SHA-256 جدول کے ساتھ درجہ 14 پر 1,911,152، اور Keccak جدول کے ساتھ درجہ 12 پر 3,346,865۔ یہ سب چین 18 تا 20 کی 4 MiB حد کے اندر رہتے ہیں۔
پہلے سے تیار تصدیقی کلید کے ساتھ تصدیق میں تقریباً 16 ms لگتے ہیں، اور جب کوئی (tier, heights) کلید پہلی بار بنتی ہے تو تقریباً 230 ms۔ test FRI پروفائل (16 سوالات) ٹیسٹ سوئٹ کے لیے موجود ہے اور غیر محفوظ ہے؛ چین 20 کا جینیسس production مقرر کرتا ہے۔ Fullnode v0.6.8 کسی قید کو نہیں بدلتا: چین 20 وہی hc_bundle اور hc_auth مقرر کرتی ہے جو چین 17 تا 19 نے کیے تھے۔
ہیش ساختیں جنہیں آپ خود دوبارہ بنا سکتے ہیں
ڈومین کے ساتھ BLAKE3: blake3(domain || data)، ڈومین سٹرنگ کسی فاصل کے بغیر۔
بائنڈنگ ڈومین۔ چین 20 کا جینیسس binding_domain: 1 مقرر کرتا ہے (fullnode v0.6.8، آڈٹ v6 BIND-1)۔ ایسی چین پر ہر ثبوتی بائنڈنگ اور ہر دستخط شدہ عمل کا پیغام، جو پہلے صرف چین کی شناخت سے بندھا تھا، اب جینیسس ہیش سے بھی بندھتا ہے: ڈومین کا ورژن نمبر ایک بڑھ جاتا ہے اور 32 بائٹ کا جینیسس ہیش پری امیج میں سب سے پہلے، چین کی شناخت سے پہلے، آتا ہے۔ یوں ایک چین کے لیے بنایا گیا ثبوت یا دستخط کسی دوسری چین پر تصدیق نہیں پاتا، اس چین پر بھی نہیں جو وہی چین شناخت اور وہی کلیدیں دوبارہ استعمال کرے، جیسا کہ ری کٹ میں ہوتا ہے۔ بائنڈنگ الفاظ ثبوتوں کا عوامی ان پٹ ہیں، اس لیے کوئی گیسٹ یا تصدیقی کلید نہیں بدلی۔ جدول دونوں صورتیں دیتا ہے؛ چین 14 تا 19 پہلی صورت بائٹ بہ بائٹ استعمال کرتی ہیں۔ جو پہلے سے جینیسس سے بندھے تھے اور بدستور ہیں: ووٹ اور تجاویز (consensus_domain: 1 کے بعد سے)، v2 Registration، اور AdmitValidator ووٹ۔ جو منتقل نہیں ہوا: برج کا اجرائی شریک دستخط (اوپر)۔ چین 20 پر بھیجنے کے لیے والیٹ کو v0.6.8 درکار ہے، اور والیٹ صورت کا فیصلہ چین کی شناخت سے کرتا ہے، نوڈ کے دعوے سے نہیں؛ rand_getLimits.binding_domain اسے بتاتا ہے۔
| قدر | ساخت |
|---|---|
| شفاف پتہ | blake3("rand-address" || dilithium2_public_key)، base58 |
| ٹرانزیکشن شناخت | blake3("rand-txid-3" || bincode(view))، جہاں view وہ ٹرانزیکشن ہے جس میں بنڈل کے ثبوتی بائٹس کی جگہ blake3(proof) اور اس کے اجازتی ثبوت کی جگہ blake3(auth_proof) رکھا گیا ہو؛ auth_commit جوں کا توں شامل ہوتا ہے۔ چین 16 تک ڈومین rand-txid-2 تھا، اجازتی فیلڈز کے بغیر |
| ٹرانزیکشن بائنڈنگ | چین 14 تا 19 پر blake3("rand-tx-bind-1" || bincode(chain_id, bundle', action'))؛ چین 20 پر blake3("rand-tx-bind-2" || bincode(genesis_hash, chain_id, bundle', action'))۔ آٹھ لٹل اینڈین u32 الفاظ، جہاں ' کا مطلب ہے کہ bundle.proof، bundle.auth_proof اور کسی Aggregate کا proof خالی ویکٹر سے بدل دیے گئے ہیں؛ bincode مقررہ چوڑائی کے لٹل اینڈین اعداد صحیحہ کے ساتھ۔ ہر بنڈل ثبوت اور اجازتی ثبوت انہی الفاظ پر بنایا جاتا ہے اور انہی کے مقابل اس کی تصدیق ہوتی ہے |
| کال بائنڈنگ | blake3("rand-call-bind-1" || …)، یا چین 20 پر جینیسس ہیش کو پہلے رکھ کر rand-call-bind-2: ٹرانزیکشن بائنڈنگ والی ساخت، جس میں Call (یا Invoke) کا اپنا proof بھی خالی کر دیا جاتا ہے۔ hardening_v6 جینیسس پر، جیسے چین 20، کال ثبوت کا عوامی حصہ پروگرام کے ڈیپلائے کے وقت کے عوامی الفاظ پر مشتمل ہوتا ہے جن کے بعد یہ آٹھ الفاظ آتے ہیں، اور Invoke کا ثبوت ان کے بعد اپنی منتقلی کو سیاقی الفاظ کے طور پر شامل کرتا ہے |
| پروگرام شناخت | blake3("rand-program" || base_pc as 4 LE bytes || words as 4 LE bytes each) |
| p2p شناخت | blake3("rand-p2p-identity" || seed) سے ماخوذ ed25519 کلید |
| برج اثاثہ شناخت (فی پشت پناہی) | blake3("rand-bridge-asset" || token_chain as 2 BE bytes || token_address (32 bytes)) — rand_bridgeAssetId اس کا حساب کرتا ہے اور rand_getAssets اسے پشت پناہی کی ہر قطار کے ساتھ دکھاتا ہے؛ یہ ترسیل میں ماخذ سکے کی شناخت کرتی ہے، ٹوکن کی نہیں |
| RPL ٹوکن اثاثہ شناخت، مقامی | blake3("rand-rpl-asset" || bincode(name, symbol, decimals, authority, initial: Option<InitialMint>, salt))، جہاں salt تخلیق کار کے منتخب کردہ 32 بائٹ ہیں؛ ہیکس میں اور rpl1… کی صورت میں دکھائی جاتی ہے |
| RPL ٹوکن اثاثہ شناخت، برج شدہ | blake3("rand-rpl-asset" || bincode(name, symbol, BRIDGE_DECIMALS, salt)) — کسی (chain, token) جوڑے پر نہیں، کیونکہ ایک برج شدہ ٹوکن کئی پشت پناہیوں پر محیط ہوتا ہے |
| برج ڈپازٹ اخفا | r = blake3("rand-deposit-r-1" || mu)، وہ واحد r جسے داخلہ کسی BridgeAttest کے لیے قبول کرتا ہے (ورنہ WrongDepositBlinding) |
| برج فیس نوٹ کے اخفا (چین 20) | ڈپازٹ کا فیس نوٹ: r = blake3("rand-bridge-fee-r-1" || mu)؛ برن کا: r = blake3("rand-bridge-burn-fee-r-1" || txid)؛ دونوں آٹھ لٹل اینڈین الفاظ کے طور پر پڑھے جاتے ہیں۔ ان نوٹوں کا کوئی لفافہ نہیں ہوتا: ہر فیلڈ عوامی ہے، اور مالک جینیسس کا bridge.fees.recipient ہے |
| برج وصول کنندہ | مکمل پوشیدہ پتے پر blake3("rand-shielded-recipient" || pk_bytes || kem_ek) |
فاسیٹ Mint پیغام | blake3("rand-mint-2" || bincode(chain_id, cm, pk, time, r, envelope, amount))؛ چین 20 پر blake3("rand-mint-3" || bincode(genesis_hash, chain_id, cm, pk, time, r, envelope, amount)) |
TokenMint، SetAuthority پیغامات | blake3("rand-rpl-mint-1" or "rand-rpl-authority-1", chain_id || asset_id || nonce || body)؛ اجرا کے متن میں blake3(bincode(envelope)) شامل ہوتا ہے۔ چین 20 پر rand-rpl-mint-2 اور rand-rpl-authority-2، جینیسس ہیش سب سے پہلے |
Registration پیغام | ایسے جینیسس پر جس میں staking.registration_v2 یا binding_domain: 1 ہو، جیسے چین 20، blake3("rand-register-2" || bincode(genesis_hash, chain_id, validator, payout)) (وہاں v1 رجسٹریشن رد کر دی جاتی ہے)؛ دیگر جگہوں پر blake3("rand-register" || bincode(chain_id, payout)) |
AdmitValidator ووٹ (چین 20) | blake3("rand-admit-validator-1" || genesis_hash || candidate_address)، جس پر ووٹ دینے والا ہر توثیق کار دستخط کرتا ہے |
Unbond پیغام | blake3("rand-unbond" || bincode(chain_id, validator, amount, nonce))؛ چین 20 پر blake3("rand-unbond-2" || bincode(genesis_hash, chain_id, validator, amount, nonce)) |
Withdraw پیغام | blake3("rand-withdraw" || bincode(chain_id, validator, amount, nonce, time, r, envelope))؛ چین 20 پر rand-withdraw-2، جینیسس ہیش سب سے پہلے |
| Merkle نوڈ (حالت کے درخت) | blake3("rand-merkle-node" || left || right) |
| ٹوکن رجسٹری کا پتّا | blake3("rand-token-leaf-1" || bincode(TokenInfo))، اشاریے کی ترتیب میں، tokens_root کے تحت |
| حالت کی جڑ | چین 20 پر، inner = blake3("rand-state-8" || tree_root || nullifier_root || validators_root || programs_root || bridge_root || tokens_root || faucet_epoch || faucet_minted_in_epoch || bond_queue_root || gas_price || byte_price || program_state_root) کے گرد blake3("rand-state-admitted-1" || inner || admitted_root)، جہاں program_state_root = blake3("rand-program-state-1" || cells_root || vaults_root) (RPL-2) ہے، فاسیٹ کے دونوں کاؤنٹر اور دونوں موجودہ قیمتیں ہر ایک 8 بگ اینڈین بائٹ ہیں، اور بیرونی غلاف داخل شدہ مجموعے کا عہد کرتا ہے (staking.admission_by_vote)۔ چین 19 کی جڑ انہی فیلڈز پر byte_price تک blake3("rand-state-7" || …) تھی (جینیسس کا staking حصہ tokens_root کے بعد تینوں فیلڈز rand-state-5 کے تحت جوڑتا ہے، جیسا کہ چین 15 تا 17 پر؛ جینیسس کا gas.dynamic حصہ دونوں قیمتیں جوڑتا ہے اور ڈومین کو rand-state-7 پر لے جاتا ہے)؛ چین 14 پر پہلے چھ پر rand-state-4؛ اور ایسی چین پر جس میں bridge، tokens یا aggregation حصہ نہ ہو، پہلے چار پر rand-state-2 (اجماع) |
ڈومین ٹیگ کے ساتھ Poseidon2: H(domain, msg) = sponge_hash([domain, msg...])، جس میں ٹیگ پہلا جذب ہونے والا لفظ ہے، ہر لفظ ایک Goldilocks عنصر ہے، اور 4 عناصر والا ڈائجسٹ آٹھ u32 الفاظ میں تقسیم ہوتا ہے (ہر عنصر کا پہلے نچلا نصف، پھر اوپری نصف)۔ ڈومین ٹیگ:
| ٹیگ | قدر | ساخت |
|---|---|---|
NK | 1 | مشاہداتی کلید nk = H(1, sk) |
PK | 2 | نوٹ کی عوامی قدر pk = H(2, nk) |
NF | 3 | نلیفائر H(3, nk || cm) |
CM | 4 | نوٹ کمٹمنٹ H(4, pk(8) || from(8) || amount_lo || amount_hi || asset || time || r(8)) — 28 الفاظ |
OVK, KEM_SEED | 5, 6 | بیرونی مشاہداتی کلید اور ML-KEM بیج، کاؤنٹر موڈ کے وسیع ہیش [domain, nk, counter] کے ذریعے |
NODE | 7 | درخت کا نوڈ H(7, left || right)؛ خالی پتا مکمل طور پر صفر ہوتا ہے |
HC | 8 | پروگرام کا ڈائجسٹ؛ ٹیگ، base_pc اور len پہلی پرمیوٹیشن کی گنجائشی لینز میں رکھے جاتے ہیں، پھر الفاظ فی بلاک چار کے حساب سے جذب کیے جاتے ہیں |
OUT | 9 | ٹرانسفر گیسٹ کا آؤٹ پٹ ڈائجسٹ |
IN | 10 | H_IN: گنجائشی ہیڈر [10, n_in, 0]، پھر 4 الفاظ کا سالٹ، پھر ان پٹس |
BUNDLE | 11 | متروک 2-ان-2-آؤٹ بنڈل کا ڈائجسٹ، 47 عوامی الفاظ پر؛ اب کوئی چین اس گیسٹ کو مقرر نہیں کرتی |
| پوشیدہ بنڈل | 64 | چین 14 تا 16 پر پوشیدہ اثاثے والے بنڈل کا ڈائجسٹ، 81 الفاظ پر: اینکر، چار نلیفائر، چار کمٹمنٹ، fee، burn_a، burn_r (ہر ایک دو الفاظ)، burn_asset، time، اور آخر میں ٹینٹ لفظ۔ چین 17 تا 20 (بنڈل گیسٹ v3) پر یہ 89 الفاظ پر مشتمل ہے: اجازتی کمٹمنٹ c کے آٹھ الفاظ ٹینٹ لفظ سے فوراً پہلے آتے ہیں۔ نجی اثاثہ A اس میں شامل نہیں۔ یہ ٹیگ نوڈ کی سطح کا ہے اور شامل شدہ ٹیگز 1 تا 15 سے الگ رہتا ہے |
AUTH | 65 | اجازتی کمٹمنٹ c = H(65, nk || salt)، 16 الفاظ، ہر بنڈل کے لیے نئے 256-بٹ سالٹ کے ساتھ؛ اسے بنڈل پروف اپنے ڈائجسٹ کے اندر اور آتھ پروف اپنے آٹھ آؤٹ پٹ الفاظ کے طور پر شائع کرتا ہے، اور بنڈل اسے auth_commit کے طور پر ساتھ رکھتا ہے (چین 17 تا 20)۔ 64 کی طرح نوڈ کی سطح کا |
PUB | 15 | H_PUB: ہیڈر [15, n_pub, 0]، کوئی سالٹ نہیں؛ کسی پروگرام کے لیے، چین 20 پر الفاظ ڈیپلائے کے وقت مقرر ہو جاتے ہیں (زیادہ سے زیادہ 32,768)، ہر کال کا سیگمنٹ انہی الفاظ پر مشتمل ہوتا ہے جن کے بعد کال بائنڈنگ کے آٹھ الفاظ آتے ہیں، اور کال کی جانچ اسی سیگمنٹ کے ڈائجسٹ کے مقابل کی جاتی ہے؛ بنڈل پروف اور آتھ پروف کے لیے سیگمنٹ ٹرانزیکشن کے آٹھ بائنڈنگ الفاظ ہیں؛ جس جینیسس میں max_program_public_words نہ ہو وہ صرف خالی سیگمنٹ قبول کرتا ہے |
hc، H_IN اور H_PUB سادہ پیغام سے پہلے لگے سابقے والے اسپنج نہیں ہیں: ہیڈر گنجائش میں جاتا ہے تاکہ cpu ٹیبل میں ڈائجسٹ کی قطاریں ہر پرمیوٹیشن میں ٹھیک چار الفاظ جذب کریں۔ انہیں ہاتھ سے بنانے کے بجائے شامل شدہ کریٹ (randprotocol_zkvm::hash::{input_digest, public_digest}، isa::Program::digest) سے دوبارہ تیار کریں۔
سادہ اسپنج پیڈنگ نہیں کرتا، اس لیے پہلے بلاک کے اندر [a] اور [a, 0] کا ہیش یکساں آتا ہے۔ اوپر کی ہر ساخت ایک مقررہ لمبائی کے پیغام کو اس کے اپنے ٹیگ کے تحت ہیش کرتی ہے۔ متغیر لمبائی والے ڈیٹا کے لیے، قیود کے مجموعے 7 نے لمبائی سے مقید اسپنج (hash::sponge_hash_len، POSEIDON2_LEN سسکال) شامل کیا: یہ حالت [0, 0, 0, 0, n, 0, 0, 0] سے شروع ہوتا ہے، جہاں n الفاظ کی تعداد ہے، اور کم از کم ایک بار پرمیوٹ کرتا ہے۔ یہ انہی الفاظ کا ایک مختلف ہیش ہے، اور چین پر کوئی نوٹ، نلیفائر، روٹ یا ڈائجسٹ اسے استعمال نہیں کرتا۔
دو خصوصیات یاد رکھنے کی ہیں: hc پابند کرنے والا ہے مگر چھپانے والا نہیں (کوئی سالٹ نہیں، اس لیے اندازے سے لگائے گئے پروگرام کی تصدیق ہو سکتی ہے اور ایک ہی پروگرام کی دو ڈیپلائمنٹس کو آپس میں جوڑا جا سکتا ہے)، اور H_IN پابند کرنے کے ساتھ چھپانے والا بھی ہے (ہر پروف کے لیے نیا 128-بٹ سالٹ)، اس لیے H_IN شائع کرنے سے ان پٹس کے بارے میں کچھ ظاہر نہیں ہوتا جب تک سالٹ رکھنے والا اسے کھول نہ دے۔
کلیدوں کا اخذ
| کلید | ماخذ |
|---|---|
| Dilithium2 کلیدی جوڑا (نوڈ) | 32-بائٹ بیج سے متعین طور پر |
| libp2p ed25519 (نوڈ) | blake3("rand-p2p-identity" || seed) |
مشاہداتی کلید، pk، ovk، ML-KEM کلیدی جوڑا (والٹ) | خرچ کی کلید سے Poseidon2 کے ذریعے اخذ، جیسا کہ اوپر جدول میں ہے؛ ML-KEM جوڑا MlKem768::from_seed(kem_seed) ہے |
مقالات کے صفحے پر موجود مقالات سلامتی کے دلائل پیش کرتے ہیں: پوسٹ کوانٹم انتخاب، FRI کی درستی کا حساب اور 80 سوالات رکھنے کی وجہ، اور ٹریس کی لمبائی کی حد۔