پل

دا پاڼه د پل سره د یوځای کېدو لپاره وکاروئ: په سرچینه زنځیر کې د زېرمې جوړولو، په Rand کې د تصدیق سپارلو، د پل شوې شتمنۍ د سوځولو او بېرته ایستلو، او د پل د عامه حالت لوستلو لپاره. زنځیر 20، اوسنی testnet (له 2026-10-01 06:17 UTC راهیسې فعال، بشپړ نوډ v0.6.8)، د bridge برخې سره جوړ شو: اته ساتونکي چې د ساتونکو له ټولګې شمېرې 1 پیلېږي، اته کوانټم وروسته ساتونکي، د ځنډولو کیلي، د Ethereum، BSC، Tron او Solana لپاره خپرونکي (لومړني درې هغه پایټکي دي چې په 2026-09-30 بیا ځای پر ځای شول)، د rules-v2 ډله چې د صدور نړیوال سقف یې په هرو ښوییدونکو 24 ساعتونو کې 4,000 zUSD دی، د راتلونکو پیغامونو د بیا تکرار ټیټه پوله، او په v0.6.8 کې دوه نوې ډلې: فیسونه چې په هر صدور او هره سوځونه کې 10 bps دي او په zUSD اخیستل کېږي، او د څرخولو قواعد چې د کوانټم وروسته ټولګې یا د ځنډولو کیلي څرخول اړ باسي چې د نویو کیلیو لرل ثابت کړي او یوه ورځ انتظار وباسي. د زنځیر 14 برعکس، د دې پیدایښت zUSD له اوو واړو ملاتړونو سره لېست کوي او هغه ساتنه لېږدوي چې له زنځیر 14 راهیسې له هرې پرېکړې سره راغلې ده (له زنځیر 14 څخه لېږدول شوې). rand_getAssets او د سپړونکي /bridge/assets د هر ملاتړ اوسنی locked ورکوي.

بهیر

source chain (Ethereum / BSC / Tron / Solana)                 Rand
┌────────────────────────────────┐                           ┌────────────────────────────────┐
│ lock tokens, emit              │  guardians observe,       │ BridgeAttest transaction        │
│ (amount, token, to, fee)       │  sign mu = keccak²(body)  │   admission → one deposit note  │
└────────────────────────────────┘  threshold n·2/3 + 1      │   computed by the chain          │
              ▲                     + Dilithium2 co-signers  │                                  │
   release after guardian         guardian committee         │ BridgeBurn transaction           │
   signatures on the burn  ◄───── secp256k1 keys ◄─────────  │   one bundle: slots 0–1 burn the │
   message                        read the burn log          │   asset, 2–3 pay the RAND fee;   │
                                                             │   emits a sequenced burn message │
                                                             └────────────────────────────────┘

راتلونکی: ارزښت په سرچینه زنځیر کې قلفېږي، ساتونکي یې تصدیقوي، هر څوک کولی شي تصدیق Rand ته وسپاري، او لیجر د ترلاسه کوونکي لپاره د زېرمې یو نوټ ورزیاتوي — یو نوټ چې د asset کلمه یې د پل شوې نښې د راجستر شمېره ده. وتونکی: د Rand یوه راکړه ورکړه د هغې شتمنۍ نوټونه سوځوي او یو پیغام خپروي؛ ساتونکي هغه پیغام تصدیقوي؛ د سرچینې زنځیر قرارداد یې خوشې کوي. Rand هېڅکله د سرچینې زنځیر سرلیک یا د حالت ثبوت نه تاییدوي: د ساتونکو د کمېټې لاسلیکونه د باور ټول ماډل دی.

د باور ماډل او د زنځیرونو پېژندونه

د پل سیمه‌ییز د زنځیرونو پېژندونه چې له قراردادونو سره شریک دي (bridge-codec):

ساتونکي د secp256k1 کیلیو یوه کمېټه ده؛ د ساتونکي هویت د keccak256(uncompressed_pubkey[1..]) وروستي 20 بایټه دي، چې د Ethereum د پتې د ترلاسه کولو طریقه ده، نو یوه کیلي په EVM قراردادونو، د Solana پروګرام او Rand باندې کار کوي. د n په اندازه ټولګې لپاره نصاب n·2/3 + 1 دی. هر لاسلیک باید ټیټ-s (s ≤ n/2) وي، چې د بدلون وړتیا مخه نیسي. هغه لنډیز چې ساتونکي یې لاسلیکوي mu = keccak256(keccak256(body_bytes)) دی. د ساتونکو د ټولګې څرخول د حکومتولۍ له خپرونکي (chain 1, keccak256("rand-bridge-governance")) څخه یو تصدیق دی، باید new_index == current + 1 ولري، او باید د اوسنۍ ټولګې لخوا لاسلیک شوی وي، نه د هغې چې ځای یې نیول شوی؛ وتونکې ټولګه د روانو لېږدونو لپاره د 86,400 ثانیو د مهلت کړکۍ ساتي. (دا د ECDSA ټولګه ده. د کوانټم وروسته ټولګه او د ځنډولو کیلي د خپلو کړنو له لارې څرخېږي، چې په زنځیر 20 کې د یوې ورځې ځنډ تېروي: لاندې.) که n·2/3 + 1 ساتونکي سره یوځای شي، کولی شي هر ارزښت صادر کړي؛ د پل ټینګښت دا محدودوي چې څومره او څومره ژر، خو دا خطر نه لرې کوي.

د راکړې ورکړې تړل. د Rand راکړه ورکړه لاسلیک نه لري: سوځونه د خپلې بنډل د STARK ثبوت له لارې اجازه ترلاسه کوي. له زنځیر 14 راهیسې د هرې بنډل ثبوت پر Transaction::binding جوړېږي او ورسره تاییدېږي — د ټولې راکړې ورکړې هش (د زنځیر پېژند، یوه بنډل له خپلو څلورو لفافو سره، او کړنه) چې یوازې د ثبوت بایټونه پکې خالي شوي. له زنځیر 17 راهیسې یوه بنډل دوه ثبوتونه لري، د بنډل ثبوت او د لګښت د اجازې ثبوت: تړل دواړه خالي کوي، د بنډل auth_commit ساتي، او دواړه ورسره تاییدېږي. د یوې ځنډېدلې سوځونې کاپي چې to، relayer_fee یا (to_chain, token) یې بدل شوي وي، یا د یو تصدیق کاپي چې time یا لفافه یې بدله شوې وي، په ثبوت کې ناکامېږي (TxError::InvalidBundleProof). په زنځیر 20 کې تړل د پیدایښت هش هم لري (د پیدایښت binding_domain: 1: rand-tx-bind-2 د پیدایښت هش، د زنځیر پېژند، بنډل او کړنې باندې)، نو هغه ثبوت چې د بل داسې زنځیر لپاره جوړ شوی وي چې ورته د زنځیر پېژند لري، هم نه تاییدېږي. والټونه او ریلیران باید هغه باینري وچلوي چې د هغه زنځیر لپاره جوړه شوې چې ورته یې سپاري: په زنځیر 20 کې v0.6.8 (په زنځیرونو 18 او 19 کې v0.6.7)؛ زوړ rand داسې ثبوتونه او لاسلیکونه جوړوي چې زنځیر 20 یې ردوي.

د ساتونکي او ریلیر ډیمونونه د بشپړ نوډ برخه نه دي؛ بشپړ نوډ شریک کوډیک او ترلاسه کوونکې نیمه برخه لري.

د لېږد بڼه

هر بشپړ عدد big-endian دی؛ د لېږد نسخه 1 ده.

د تصدیق لفافه

د بدنې سرلیک — 51 بایټه، بیا محموله

د Transfer محموله — پېژند 1، 133 بایټه

د GuardianSetUpgrade محموله — پېژند 2: id (1)، new_index (4)، n (1)، بیا n کیلي، هره 20 بایټه.

د Ethereum، BSC او Tron پتې 20 بایټه دي چې په 32 بایټي ځایونو کې له کیڼ لوري په 12 صفر بایټونو ډکېږي؛ د Solana پته ټول ځای ډکوي. Transfer باید د emitter_chain لپاره د زنځیر له ثبت شوي خپرونکي څخه راشي، او token_chain باید له خپرونکي زنځیر سره برابر وي. یو تصدیق تر ډېره 16 KiB دی. د پل ټینګښت هېڅ برخې د لېږد بڼه، کوډیک یا د سرچینې زنځیرونو ځای پر ځای شوي پایټکي نه دي بدل کړي: د کوانټم وروسته ګډ لاسلیکونه او د حکومتولۍ پیغامونه د Rand په راکړه ورکړه کې لېږدول کېږي، نه په تصدیق کې.

د ترلاسه کوونکي 32 بایټي پته

پټه پته 1,216 بایټه ده او په لېږد کې یوازې 32 بایټو ته ځای شته. د to ساحه د هغې هش لري:

to = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)     // ShieldedAddress::recipient_hash

زېرمه کوونکی په سرچینه زنځیر کې هش ټاکي، ساتونکي یې لاسلیکوي، سپارونکی بشپړه پته د BridgeAttest په کړنه کې اچوي، او لیجر هش بیا محاسبه کوي او نابرابري ردوي — که نه نو سپارونکی کولی شو وټاکي چې د بل چا زېرمه څوک ترلاسه کړي. د سرچینې زنځیرونو مخکینۍ برخې باید دا بڼه ومني؛ والټ یې چاپوي. زنځیر 11 د لنډ وخت لپاره دا ځای مستقیم د ترلاسه کوونکي پېژند کړی و؛ د پتې هغه بڼه له زنځیر 12 سره بېرته واخیستل شوه (حسابونه او پتې).

یوه نښه، ډېر ملاتړونه: zUSD

د شتمنیو راجستر نور د پل نه دی. دا د لیجر کچې د RPL نښو راجستر ته لېږدول شوی، چې اصلي او پل شوې نښې پکې شریکې دي، او د زنځیر د حالت ریښه یې د tokens_root په توګه ژمنه کوي. پل شوې نښه د راجستر هغه ننوتنه ده چې د صدور واک یې Bridge { backings } دی، او نور له یوې (chain, token) جوړې سره سمون نه لري. لومړۍ یې، zUSD، د USDT او USDC لخوا ملاتړ کېږي چې په څلورو زنځیرونو کې قلف شوي — Ethereum، Binance Smart Chain او Solana دواړه سکې لري، Tron یوازې USDT (Circle په Tron کې USDC بند کړ):

chain  token (32-byte wire form)                                                  coin  decimals
2      000000000000000000000000dac17f958d2ee523a2206206994597c13d831ec7           USDT  6
2      000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48           USDC  6
3      00000000000000000000000055d398326f99059ff775485246999027b3197955           USDT  18
3      0000000000000000000000008ac76a51cc950d9822d68b83fe1ad97b32cd580d           USDC  18
4      000000000000000000000000a614f803b6fd780986a42c78ec9c7f77e6ded13c           USDT  6
5      ce010e60afedb22717bd63192f54145a3f965a33bb82d2c7029eb2ce1e208264           USDT  6
5      c6fa7af3bedbad3a3d65f36aabc97431b1bbe4c2d2f6e0e47ca60203452f5d61           USDC  6

په زنځیر 20 کې zUSD شمېره 1 ده، rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx، نوم “Shielded USD”، 8 اعشاري ځایونه، د پیدایښت په فایل کې لېست شوې، لکه په زنځیرونو 15 تر 19 کې، له هماغه نوم، سمبول او مالګې سره چې په زنځیر 14 کې یې درلودل، نو د شتمنۍ پېژند یې (32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f) او rpl1… پېژند یې بې بدلونه لېږدول شوي (سپړونکی: GET /tokens/1). په زنځیر 14 کې دا په 256 لوړوالي کې د register_bridged_token راکړې ورکړې لخوا ثبت شوه.

Backing { chain: u16, token: [u8; 32], decimals: u8, locked: u64, minted_today: u64, mint_day: u32 }

یوه (chain, token) جوړه په ټول راجستر کې تر ډېره د یوې نښې ملاتړ کوي (TokenError::BackingTaken)؛ یوه نښه له 1 تر 32 ملاتړونه لري؛ decimals د سرچینې سکې خپل شمېر دی، له 0 تر 18، هېڅکله د پل شوې نښې 8 نه. ګډ ملاتړ یو اعلان شوی خطر دی: اوه واړه سکې په برابر نرخ zUSD ته او له zUSD څخه د تبادلې وړ دي، نو د هرې یوې د برابرۍ له لاسه ورکول د zUSD هر لرونکی زیانمنوي، او د Rand په لوري د یو ملاتړ د برخې لپاره هېڅ سقف نشته.

zUSD یوه ټوکرۍ ده. هر لرونکی د هرې لست شوې پشتوانې خطر په غاړه اخلي، نه یوازې د هغې سکې چې ده زېرمه کړې ده: یو zUSD پر حوض باندې یوه ادعا ده، او په هره هغه پشتوانه کې پوره کېدای شي چې کافي locked ولري. هېڅ شی د پشتوانې بیه نه ټاکي. د هرې لست شوې سکې د یوه واحد قفلول یو zUSD ضربوي، او سوځول کولای شي هره هغه پشتوانه وټاکي چې locked یې دا اندازه پوره کړي. نو هغه سکه چې خپل ثابت نرخ یې له لاسه ورکړی وي، په برابر ارزښت زېرمه کېدای شي، او zUSD یې د داسې سکې په لور سوځول کېدای شي چې خپل ثابت نرخ یې ساتلی وي، تر هغه چې سالمې پشتوانې تشې شي. دا زیان د ضرب د ښوېدونکو کړکیو او په ریښتیا قفل شوې ساتنې پورې محدود دی: په chain 20 کې په هرو 24 ساعتونو کې په ټولو پشتوانو کې تر ټولو ډېر 4,000 zUSD، او په هره پشتوانه کې 100,000، ضربېدای شي (rules v2)، او له یوې سالمې پشتوانې څخه تر هغه څه ډېر نه شي وتلی چې هغه پشتوانه یې لري. کړکۍ سرعت محدودوي، نه ټوله اندازه: هغه وخت برابروي چې ضرب ودرول شي، چې دا د کمزورې سکې نوې زېرمې دروي او سوځول خلاص پاتې کېږي. د هرې پشتوانې لپاره د بېرته اخیستو کومه حد نشته او د هرې پشتوانې لپاره ځانګړی درول هم نشته. په chain 14 کې، له rules v2 مخکې، یوازینی حد د سرچینې پای‌ټکو خپل درولونکی او د هر توکن د سرعت حدونه وو.

ثابت شرط: total_supply == Σ backings.locked. TokenRegistry::lock (یو BridgeAttest) تایید شوې اندازه په یوه ځل د پشتوانې په locked او د توکن په total_supply دواړو کې ورزیاتوي؛ TokenRegistry::release (یو BridgeBurn) خوشې شوې اندازه له دواړو څخه کموي. بل هېڅ شی دا دوه ساحې نه لیکي، او د توکن پاڼه د هرې پشتوانې locked په tokens_root کې ژمنه کوي، نو هغه دوه نوډونه چې پر یوه یې اختلاف ولري، د حالت په ریښه کې سره جلا کېږي. د سرچینې پای‌ټکي پر قفلولو هېڅ فیس نه اخلي او پر خوشې کولو ټوله تایید شوې اندازه کموي، نو د هرې پشتوانې locked د هغه پای‌ټکي له ساتنې سره برابر دی، پرته له هغو پیغامونو چې لا په لاره کې دي. په chain 20 کې فیسونه دا شرط نه ماتوي: فیس یو zUSD نوټ دی چې صادر او ملاتړ شوی پاتې کېږي، نو زېرمه بیا هم ټوله ناخالصه اندازه قفلوي او سوځول یوازې amount − fee خوشې کوي. په chain 20 کې د USDT پر خوشې کولو د پای‌ټکو خپل 10 bps کسر د ګوښه کېدو پر وخت 0 ته واړول شو؛ اوس فیس پر Rand اخیستل کېږي.

اندازې د تار پر سر په ۸-اعشاري واحدونو کې دي، که د سرچینې سکې خپل اعشار هر څومره وي: له Ethereum (۶ اعشاره) څخه د 1 USDT زېرمه د 100_000_000 واحدونو په توګه قفلېږي. یوازې شاخص 0، RAND، د دې چین نهه اعشاره لري.

یو توکن باید له لومړۍ زېرمې مخکې لست شي. نور د لومړي لیدو پر مهال ثبت نشته: هغه تایید چې داسې (chain, token) نوموي چې چا لست کړی نه وي، د BridgeError::UnlistedToken (token … of chain … is not listed on this chain) سره ردېږي. پیسې د سرچینې پای‌ټکي په ساتنه کې پاتې کېږي تر هغه چې د ساتونکو یوه پوسټ‌کوانټم کوروم سکه لست کړي (له genesis وروسته لست کول).

asset_id = blake3("rand-bridge-asset" || token_chain (2 bytes BE) || token_address (32 bytes))

rand_bridgeAssetId(token_chain, token_address) لا هم دا پر هر چین محاسبه کوي، او همدا هغه څه دي چې د یوه Transfer بار (token_chain, token_address) ورته حل کېږي، خو نور د ثبت کلي نه دی. هغه څه چې یو نوټ او یوه بټوه یې لېږدوي، د توکن شاخص دی، یو ګڼ u32: شاخص 0 RAND دی او هېڅکله په ثبت کې نه وي. rand_getAssets د هرې پشتوانې لپاره یو قطار لري، او د یوه توکن ټول قطارونه د یوه شاخص لاندې دي:

[{ "index": 1, "chain": 2, "token": "000000000000000000000000dac17f…", "asset_id": "…", "decimals": 6,
   "locked": "0", "mint_cap_per_day": "10000000000000", "minted_today": "0", "mint_day": 20716 }]

locked، mint_cap_per_day او minted_today په ۸-اعشاري واحدونو کې لسیز متنونه دي، لکه هر u64 اندازه چې RPC یې له chain 14 راهیسې وړاندې کوي؛ index، chain، decimals او mint_day شمېرې پاتې کېږي. د توکن په کچه میتودونه — rand_getTokens، rand_getToken، rand_getTokenSupply — یو پل شوی توکن د یوه قطار په توګه راګرځوي چې ټولې پشتوانې یې پکې دي (RPL توکنونه). د explorer GET /bridge/tokens د هغو سکو ثابت اجازه‌لېک دی چې پل یې مني.

راتلونکی: BridgeAttest

Action::BridgeAttest { attestation: Vec<u8>, recipient: ShieldedAddress, r: Word8, time: u32,
                       asset: u32, envelope: Envelope, pq_signatures: Vec<PqSignature> }

PqSignature { index: u8, signature: Vec<u8> }        // Dilithium2, 2,420 bytes

دا د یوې عادي پټې معاملې له لارې لېږدول کېږي چې یوازینی پټ‌شتمنۍ بنډل یې 0.001 RAND اساسي فیس ورکوي او نور هېڅ نه: د هغې لېږدوونکی د داسې زېرمه کوونکي لپاره پیسې ورکوي چې لا هېڅ RAND نه لري. چین، نه سپارونکی، د زېرمې نوټ { pk: recipient.pk, from: 0, amount, asset: <index>, time, r } له هغې اندازې څخه محاسبه کوي چې ساتونکو لاسلیک کړې ده، نو لېږدوونکی نه شي کولای ضرب لوی کړي یا بل لوري ته یې واړوي؛ د هغه ژمنه هغه یوازینۍ پاڼه ده چې معامله یې د تار پر سر نه لېږدوي. په chain 20 کې د نوټ amount ناخالصه اندازه منفي د ضرب فیس ده، او چین دوهم نوټ، یعنې فیس، خزانې ته ورزیاتوي (د ضرب او سوځولو فیسونه).

پټوونکی ارزښت مشتق کېږي، نه ټاکل کېږي. r باید دا وي

r = blake3("rand-deposit-r-1" || mu)        // read as eight little-endian words; mu = keccak256(keccak256(body))

هغه ډایجسټ چې د ساتونکو کوروم لاسلیک کړی دی؛ هر بل څه BridgeError::WrongDepositBlinding دی، چې د لاسلیک له هر کار مخکې ردېږي. ساحه د تار پر سر پاتې کېږي — د بټوې د عامو ساحو بیارغونه یې هلته لولي — یوازې محدوده شوې ده، او دا قاعده د تاوېدو تایید هم رانغاړي. له دې مخکې، هر چا چې د یوه لېږدوونکي ځنډېدلې معامله لیدلې وای، کولای یې شول همغه تایید د خپل پټوونکي ارزښت لاندې وسپاري: ترلاسه کوونکي بیا هم نوټ ترلاسه کاوه، خو د لېږدوونکي معامله د ثبوت د پیسو له ورکولو وروسته له منځه تله. د ثابت r سره، د یوه تایید دوه سپارونکي په یوه time کې یو نوټ نوموي او حوض یې پر ژمنه باندې سره متضاد ګڼي.

time او asset د زېرمه کوونکي دوه وړاندوینې دي، چې ځکه کېږي ترڅو لفافه د معاملې له شتون مخکې مهر شي. time په همغه کړکۍ کې ساتل کېږي چې د بنډل یې ساتل کېږي (په chain 20 کې 1,024 بلاکونه، د genesis له proof_window_blocks څخه؛ مخکې 256)، او په قصدي توګه نه مشتق کېږي: هېڅ قاعده داسې time نه ورکوي چې ټول سپارونکي پرې موافق شي، نو مخکې‌ځغاستونکی لا هم کولای شي په کړکۍ کې بل time وټاکي — د همغه ترلاسه کوونکي، اندازې او شتمنۍ یو بل نوټ، چې د ترلاسه کوونکي بټوه یې په همغه ډول پیدا کوي — او دوه سپارنې پر ځای یې د تایید پر ډایجسټ سره ټکر کوي. asset باید له هغه شاخص سره برابر وي چې ثبت مخکې (chain, token) ته ورکړی دی، که نه TxError::AttestAssetMismatch.

د Transfer بار fee لېږدول کېږي او هېچا ته نه ورکول کېږي: د سپارونکي هېڅ هویت نشته چې ورته ورکړل شي، نو زېرمه ناخالصه اندازه ده، یوازې د چین خپل د ضرب فیس ترې کمېږي چېرې چې genesis یې ټاکي (chain 20). د بیا تکرار پر وړاندې ساتنه د ډایجسټ له لارې ده: هر مصرف شوی mu د پل spent ټولګې ته ځي، او mempool هغه دوهم لېږدوونکی ردوي چې د همغه تایید لپاره سیالي کوي. یوه زېرمه د پشتوانې د ضرب حد ته هم تابع ده، په chain 20 کې نړیوال حد ته هم، او کله چې ضرب درول شوی وي ردېږي (B1، rules v2). دواړه حدونه ناخالصه اندازه شمېري. پر هغه چین چې genesis یې د بیا تکرار کښتنی حد ټاکي، chain 20 په ګډون، هغه لېږد چې sequence یې د خپل سرچینې چین له کښتني حد څخه ټیټ وي، د هر لاسلیک له کتلو مخکې د BelowReplayFloor سره ردېږي (له chain 14 څخه راوړل شوي).

rand bridge-mint <attestation hex or @file> --pq <JSON or @file> [--to rand1…] [--fee <RAND>] [--no-wait]
rand bridge-rotate <rotation hex or @file> --pq <JSON or @file> [--fee <RAND>] [--no-wait]

--pq اړین دی: د ساتونکو د Dilithium2 ګډ لاسلیک کوروم د [{"index":0,"signature":"<4840 hex>"},…] په توګه. له هر ثبوت جوړولو مخکې بټوه تایید ډیکوډ کوي، کوروم د نوډ له pq_guardians او د چین له پېژند سره پرتله کوي، ګوري چې ترلاسه کوونکی هش کېږي هغه تایید شوي ته، او لست شوی شاخص لولي؛ بیا r مشتق کوي، د ترلاسه کوونکي لفافه مهروي (پر هغه چین چې فیسونه لري د خالصې اندازې لپاره) او د خپل RAND له یوه بنډل سره پیسې ورکوي. bridge-rotate د ساتونکو د ټولګې تاوېدل (بار 2) سپاري، چې هېڅ نه زېرمه کوي، او هر هغه څه ردوي چې د Rand ټولګه یو ګام وړاندې نه بیايي. څرنګه چې د زېرمې د نوټ هره ساحه په همغه یوه معامله کې عامه ده، د ترلاسه کوونکي بټوه هغه زېرمې نوټونه چې هغه ته ورلېږل شوي، د ژمنه شویو bridge_attest معاملو په تېرېدو بیارغوي، پرته له دې چې کومه لفافه پرانیستل شي — یو دښمن لېږدوونکی کولای شي بې‌ګټې څه مهر کړي، خو نوټ نه شي پټولی.

وتونکی: BridgeBurn

Transaction {
  chain_id,
  bundle: <hidden-asset bundle: slots 0–1 spend the token, slots 2–3 pay the RAND fee;
           burn_asset = asset, burn_a = amount, burn_r = 0, fee >= BRIDGE_BURN_FEE>,
  action: BridgeBurn { asset, amount, relayer_fee, to_chain, token, to }
}

د chain 14 د پټ‌شتمنۍ بنډل راهیسې، سوځول یو بنډل دی (مخکې دوه وو): ځایونه 0–1 ثابتوي چې سوځوونکی د شتمنۍ د داسې نوټونو خاوند و چې مجموعه یې لږ تر لږه amount ده، او burn_a هغه ارزښت دی چې له حوض څخه وځي، او ځایونه 2–3 فیس په RAND ورکوي. فیس BRIDGE_BURN_FEE دی، 0.01 RAND، چې د بنډل اساسي فیس پوښي. relayer_fee د amount یوه برخه ده (fee ≤ amount) چې د موخې پر چین د خوشې کولو قرارداد له خوا جلا کېږي، نه اضافي لګښت، نو burn_a دقیقاً amount دی. په chain 20 کې چین د amount د 10 bps سوځولو فیس هم د یوه zUSD نوټ په توګه خزانې ته ساتي، او خوشې کول amount − fee دي؛ د لېږدوونکي برخه باید په همدې خوشې کولو کې ځای شي (د ضرب او سوځولو فیسونه).

سوځول خپله سکه نوموي. (to_chain, token) باید د سوځول شوې شتمنۍ یوه پشتوانه وي (که نه TokenError::NotABacking)، او دوه قاعدې د عمل په پړاو کې، د بنډل له ثبوت مخکې، کتل کېږي:

• د خوشې کولو واحد. هغه پشتوانه چې d < 8 سرچینې اعشاره لري، د 10^(8−d) په واحدونو خوشې کوي (د ۶-اعشاري سکې لپاره 100؛ د ۱۸-اعشاري سکې لپاره 1). خوشې شوې اندازه او relayer_fee باید هر یو بشپړ مضرب وي، که نه TokenError::NotReleasable (… is not a multiple of the release unit …): د سرچینې سکې تر کوچني واحد کوچنۍ برخه به په ساتنه کې بنده پاتې شي.
• د پشتوانې خپله ساتنه. خوشې شوې اندازه د هغې پشتوانې لپاره ≤ locked، که نه TokenError::InsufficientBacking (only … is locked in that backing, not the … asked for). د توکن ټول عرضه ښايي خوشې کول پوره کړي؛ خو د همدې یوې پشتوانې ساتنه ده چې باید یې پوره کړي.

خوشې شوې اندازه پر هغه چین چې فیس نه لري amount ده او په chain 20 کې amount − fee.

to باید سمه بڼه ولري (په chains 2، 3 او 4 کې په صفرونو ډک 20 بایټه؛ هېڅکله ټول صفر نه). لیجر یو BridgeBurnRecord د یوه په کلکه زیاتېدونکي burn_sequence لاندې ثبتوي، د معاملې هش د لېږونکي په ځای کې، او ساتونکي د سوځولو لاګ لولي:

→ {"method":"rand_getBridgeBurn","params":[13]}
← { "sequence": 13, "amount": "99900000", "fee": "99900", "release_amount": "99800100",
    "body_hex": "…", "digest": "a4bc1c7d…63f4", "tx": "ceb9e3c2…0be7", "height": 2899 }

body_hex هغه بهرنی پیغام دی چې ساتونکي یې باید دقیقاً همداسې هش او لاسلیک کړي؛ د هغه د Transfer مقدار release_amount دی. پورتنی ریکارډ د زنځیر 20 لومړی سوځول دی: 0.999 zUSD د BSC USDT په لور په 2,899 لوړوالي سوځول شوي، چې له هغو څخه 0.000999 خزانې ته ولاړل او 0.998001 خوشې شول.

rand bridge-burn <ASSET> <AMOUNT> <TO_CHAIN> <TOKEN> <TO> [--relayer-fee N] [--fee <RAND>] [--no-wait] [--yes]
rand bridge-message <SEQUENCE>       # one outbound message, verbatim, for a guardian to sign

والټ لومړی، د bridge د حالت او د ټوکن د راجستر له یوې لوستنې، له هر ډول ثبوت جوړولو مخکې، دا ګوري چې زنځیر bridge لري، چې ASSET په راجستر کې دی، چې په TO_CHAIN باندې TOKEN یې ملاتړ کوي او لږ تر لږه AMOUNT پکې تړل شوی دی، او چې AMOUNT او د ریلیر فیس د خوشې کېدو بشپړ واحدونه دي. په هغه زنځیر چې فیس لري، بیا د bridge فیس او هغه مقدار چاپوي چې خوشې کېږي، او له ثبوت جوړولو مخکې پوښتنه کوي (--yes له پوښتنې تېرېږي). وروسته یو سوځول یو بنډل ثابتوي: په لپټاپ کې شاوخوا 100 s او شاوخوا 1.5 MB ثبوت، او په زنځیر 20 کې، لکه د زنځیر 17 راهیسې د هر بنډل لپاره، ورسره د لګښت د اجازې یو ثبوت هم (څو ثانیې، شاوخوا 1.37 MB).

په ضربولو او سوځولو فیسونه

په fullnode v0.6.8 کې نوی، او په زنځیر 20 کې د پیدایښت (genesis) ډلې له خوا ټاکل شوی

"bridge": { …, "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" } }

زنځیر په هر bridge شوي ضربولو او هر bridge شوي سوځولو فیس اخلي، په bridge شوي ټوکن، په Rand، د یوه پټ یادښت په بڼه د خزانې پتې recipient ته. هره نرخ تر 100 bps (1 %) زیاته نه ده؛ په زنځیر 20 کې دواړه 10 bps، 0.1 % دي. فیس ⌊amount · bps / 10⁴⌋ دی چې د ملاتړ د خوشې کېدو بشپړ واحد ته ښکته ګرد کېږي (10^(8 − source decimals): د 6-اعشاري USDT لپاره 100 واحده، د 18-اعشاري سکې لپاره 1)، نو فیس او پاتې برخه دواړه بشپړ واحدونه دي، او هغه فیس چې صفر ته ګرد شي هېڅ یادښت نه جوړوي (ledger/bridge_notes.rs، bridge_fee).

دواړه یادښتونه صادر شوي او ملاتړ شوي دي، نو total_supply == Σ locked == custody لا هم صدق کوي: د فیس یادښت د نورو په څېر zUSD دی، او ارزښت یې د سرچینې په زنځیر کې تړل شوی پاتې کېږي تر هغه چې څوک یې وسوځوي. BRIDGE_BURN_FEE، هغه 0.01 RAND چې یو سوځول یې په خپلو RAND ځایونو کې ورکوي، بدل شوی نه دی او جلا دی.

د زنځیر 20 لومړی بشپړ ګرځښت، له نوډ څخه لوستل شوی: له BSC څخه د 1 zUSD یوې زېرمې په 1,664 لوړوالي (4f6e6c54…1a64) زېرمه کوونکي ته 0.999 zUSD او خزانې ته 0.001 ورکړل؛ BSC USDT ته د 0.999 zUSD بېرته سوځول په 2,899 لوړوالي (ترتیب 13) 0.000999 zUSD وساتل او 0.998001 یې خوشې کړل. له هغه وروسته (لوستل شوی 2026-10-01) د BSC USDT ملاتړ 22.001999 zUSD درلودل، او د ټوکن عرضه، 99.001999 zUSD، د هغه د ملاتړونو له مجموعې سره برابره وه.

خزانه خپل یادښتونه څنګه پیدا کوي. د فیس یادښت پوښ نه لري: د هغه هره کلمه عامه ده (مقدار له معاملې او د پیدایښت له نرخ، شتمني او time له معاملې، ړندونکی مشتق شوی، مالک د پیدایښت recipient). هغه والټ چې پته یې recipient ده، د فیس یادښتونه په همغه عامه تېرېدنه کې بیا جوړوي چې د زېرمې یادښتونه بیا جوړوي، او په هره همغږۍ کې یو ځل rand_getBridgeState.fees او د ملاتړونو اعشاریې لولي. هغه نوډ چې د فیسونو په اړه دروغ وايي، یوازې دا کولی شي چې یو یادښت ونه موندل شي، هېڅکله یې نشي اعتبارولی. د زېرمه کوونکي والټ هم خپله زېرمه په همدې ډول ارزوي، ناخالص منفي فیس. یوازې v0.6.8 والټ دا کار کوي؛ زوړ والټ په هر حال په زنځیر 20 کې نشي لېږلی.

له ډلې پرته، زنځیرونه 14 تر 19، فیس نشته: زېرمه ناخالص اعتباروي او سوځول amount خوشې کوي. تر زنځیر 20 پورې یوازینی bridge فیس د سرچینې endpoints خپل 10 bps کسر و چې د خوشې کېدو پر مهال یې د کوربه زنځیر پر سر له USDT څخه اخیسته؛ د زنځیر 20 د پرې کېدو پر مهال 0 ته وټاکل شو. ډله د پیدایښت په هش پورې ژمنه ده او د rand-bridge-fees-1 لاندې د bridge په ریښه کې ننوتل شوې ده. د fullnode docs/bridge.md §25 یې کوډ کول لري.

د bridge ټینګول

د هر ملاتړ locked او InsufficientBacking بېرته اخیستنه ساتي. هغوی ضربول نه محدودوي: هغه تصدیق چې د ساتونکو باوري نصاب ولري، هغه څه ضربوي چې وايي یې. درې پوړونه دا تشه تړي او څلورم اجازه ورکوي چې یو ټوکن د زنځیر له پرې کولو پرته لست شي. هېڅ یو یې د سرچینې زنځیر endpoints، د تصدیق د لېږد بڼه یا bridge-codec نه بدلوي.

B1: د هر ملاتړ لپاره د ضربولو سقف، او د ضربولو درول

د پیدایښت tokens.mint_cap_per_day د هر ملاتړ لپاره پلي کېږي: زنځیر 20 یې 10000000000000 ټاکي، د هر ملاتړ لپاره په ورځ کې 100,000 zUSD، لکه د زنځیر 14 راهیسې هر زنځیر چې کړي دي. له قواعدو v2 پرته (زنځیر 14) یوه ورځ د بلاک د وخت نښې timestamp_ms / 86_400_000 ده؛ د قواعدو v2 لاندې (زنځیرونه 15 تر 20) همدا سقف د بلاک د وخت د cap_window_secs په یوې روانې کړکۍ کې اندازه کېږي، او د ټول راجستر نړیوال سقف — په زنځیر 20 کې په 86,400 s کې 4,000 zUSD — تنګ حد دی (قواعد v2). له سقف څخه اوښتې زېرمه د ساتونکو د لاسلیک له کار مخکې د TokenError::MintCapExceeded سره رد کېږي، او کله چې کړکۍ بیا ځای ولري د منلو وړ ده.

د پیدایښت bridge.pause_key یوه Dilithium2 کیلي ده، چې له هر post-quantum ساتونکي جلا ده. دوه بې‌بنډله، بې‌فیسه کړنې:

• PauseMints { nonce, signature } — یوازې د درولو کیلي یې لاسلیک کوي. یوازې درولی شي.
• UnpauseMints { nonce, pq_signatures } — د post-quantum ساتونکو نصاب ته اړتیا لري، هېڅکله د درولو کیلي ته نه.

دواړه pause_nonce لېږدوي او زیاتوي یې، نو هېڅ یو یې بیا نشي تکرارېدلی. د درولو پر مهال هر انتقالي BridgeAttest د BridgeError::MintsPaused سره رد کېږي؛ سوځول او د ساتونکو د ډلې بدلونونه پرانیستي پاتې کېږي، نو درول هېڅکله بېرته اخیستنه نه بندوي. د قواعدو v2 لاندې (زنځیرونه 15 تر 20) د درولو پر مهال لست کول هم رد کېږي. د درولو کیلي باید د ساتونکو له کیلیو بېل ماشین کې وساتل شي.

rand bridge-pause --sig <HEX or @file> [--no-wait]        # no key file and no RAND needed
rand bridge-unpause --pq <JSON or @file> [--no-wait]

درول څه پوښي: د ساتونکو daemons چې دوکه یا جوړ جاړي شوي وي او یو جعلي ضربول په ګډه لاسلیک کړي، په داسې حال کې چې د post-quantum نصاب لرونکي نه وي. دا د هغه نصاب د غلا په وړاندې دفاع نه ده، کوم چې درول لرې کولی شي، په یوه ټوکن تر 32 ملاتړونو پورې لست کولی شي، هر یو د خپل ورځني سقف سره، او د قواعدو v2 لاندې د post-quantum ډله او د درولو کیلي بدلولی شي.

B2: محدودې د بلاک د وخت نښې

د bridge شوي زنځیر د بلاک د وخت نښه د ساتونکو د ډلې پای ته رسېدل او د ضربولو د سقف ورځ ټاکي، نو مشر باید ونشي کړای چې هغه ټوپ کړي. په هغه زنځیر چې bridge لري:

• د اعتبار یو قاعده، چې په بیا چلولو کې هم ګورل کېږي: timestamp_ms ≤ parent.timestamp_ms + 60_000، که نه BlockError::TimestampLeap. د موجوده شاته تګ د قاعدې (BlockError::TimestampRewind) سره، د بلاک وخت یوازې مخ ته ځي، په هر بلاک کې تر یوې دقیقې زیات نه.
• د رایې یو قاعده، هېڅکله د بیا چلولو قاعده نه: یو تاییدوونکی خپله رایه له هغه بلاک څخه سپموي چې د هغه له خپل ساعت څخه تر 15,000 ms زیات مخکې وي.

له دې امله په bridge شوي زنځیر هر تاییدوونکی NTP ته اړتیا لري: هغه چې تر 15 ثانیو زیات توپیر ولري، ناسم مشر او ناسم رایه ورکوونکی دی. کله چې زنځیر له درېدو وروسته ځان را رسوي، د بلاک وخت په هر بلاک کې تر 60 s پورې مخ ته تللی شي، نو د ضربولو د سقف ورځ کېدای شي له ریښتینې ورځې ګړندۍ واوړي — د راټول شوي ځنډ په هره بشپړه ورځ کې تر ډېره د یوې اضافي ورځې سقف.

B3: په هر ضربولو یو Dilithium2 ګډ لاسلیک

هر BridgeAttest، زېرمه او بدلون دواړه، باید د خپل ECDSA نصاب تر څنګ د Dilithium2 لاسلیکونو یو نصاب ولري چې پر دې باندې وي

M = "rand-bridge-pq-cosign-1" || rand_chain_id (u64 BE) || mu        // 63 bytes

mu هغه لنډیز دی چې ECDSA نصاب یې لاسلیک کوي؛ د زنځیر پېژند د testnet ګډ لاسلیک له دې ساتي چې په بل Rand زنځیر تایید شي. لاسلیکونه د کړنې په pq_signatures کې، د معاملې د تړلو دننه ځي، نو په یوه کاپي کې نه لرې کېدای شي او نه بدلېدای شي. ارزانه ازموینې له ګرانو مخکې: quorum(n) ≤ len ≤ n (PqNoQuorum)، شاخصونه په کلکه زیاتېدونکي (PqIndexOrder)، هر شاخص < n (PqIndexOutOfRange)، هر لاسلیک دقیقاً 2,420 بایټه (PqBadSignatureLength)، او په پای کې دا چې هر یو د pq_guardians[index] لاندې تایید شي (PqBadSignature). دواړه نصابونه په خپلواکه توګه شمېرل کېږي. د پیدایښت bridge.pq_guardians د پیدایښت د ECDSA ډلې (په زنځیر 20 کې ډله 1) سره د شاخص له مخې برابر دی. د payload-2 بدلون یوازې د ECDSA ډله بدلوي؛ له قواعدو v2 پرته د post-quantum ډله د زنځیر د ټول عمر لپاره ثابته ده، او د قواعدو v2 لاندې یوازې RotatePqGuardians هغه بدلوي (په زنځیر 20 کې د هغه V2 بڼه، د ملکیت د ثبوت او یوې ورځې ځنډ سره). زنځیر 20 اته لري، هماغه اته کیلي چې زنځیرونه 15 تر 19 لري؛ یو ضربول شپږو ته اړتیا لري (زنځیر 14 شپږ درلودل او پنځو ته یې اړتیا درلوده).

دا ګډ لاسلیک په chain 20 کې هم یوازې د chain id پورې تړلی دی: د لاندې حکومتي پیغامونو په څېر د genesis هش تر شا نه دی وړل شوی، ځکه هغه ساتونکي ډیمونونه چې دا لاسلیک جوړوي په بل ریپوزیټوري کې دي او بدل شوي نه دي. د یوه chain داسې کاپي چې همغه id لري او د ساتونکو ټولګه یې هم کاپي کړې وي، د یوې زېرمې (deposit) هغه ګډ لاسلیکونه به ومني چې د اصلي chain لپاره جوړ شوي وو؛ په chain 20 کې د زېرمې د راکړې ورکړې خپل د فیس بنډل له genesis سره تړلی دی، خو د هغې دننه تصدیق نه دی تړلی.

B4: له genesis وروسته د پُل شوي ټوکن لېست کول

یوه عادي پته هېڅکله د Bridge واک لرونکی ټوکن نشي جوړولی. دوه کړنې شته، هره یوه پر یوه عادي RAND فیس بنډل او هره یوه د پوسټ-کوانټم کوورم لاندې:

• RegisterBridgedToken { name, symbol, salt, chain, token, decimals, nonce, pq_signatures }: په راتلونکي انډیکس کې یو نوی پُل شوی ټوکن، په Rand کې 8 اعشاریه ځایونه، د genesis د منټ سقف لاندې، له خپل لومړي ملاتړ سره. فیس: د بنډل بنسټیز فیس جمع د راجستر registration_fee (په chain 20 کې 1 RAND، نو 1.001 RAND؛ chain 20 د راجسټرېشن فیس سوځوي، پروپوزر ته یې نه ورکوي).
• ListBacking { token_index, chain, token, decimals, nonce, pq_signatures }: پر یوه راجستر شوي پُل شوي ټوکن یو بل ملاتړ، چې له locked = 0 څخه پیلېږي. فیس: د بنډل بنسټیز فیس.

دواړه list_nonce له ځانه سره لري او یو یې پورته کوي (که نه، BadListNonce { expected, got }) او همغه ازموینې ترسره کوي: chain یو راجستر شوی خپرونکی لري (BridgeError::NoEmitter)، (chain, token) تر اوسه د هېڅ شي ملاتړ نه کوي، له 32 څخه لږ ملاتړونه، decimals ≤ 18.

rand token register-bridged --name … --symbol … --salt <hex32> --chain N --token <hex32> --decimals N --pq <JSON or @file>
rand token list-backing --asset <index> --chain N --token <hex32> --decimals N --pq <JSON or @file>

د ترتیب دوه قاعدې شته. ساتونکي لومړی راجسټرېشن لاسلیکوي، د هغه تر ثبتېدو پورې انتظار کوي، ټاکل شوی انډیکس بېرته لولي، او یوازې بیا هغه لېستونه لاسلیکوي چې دا انډیکس پکې نومول شوی وي؛ ځکه د اصلي ټوکن راجستر کول اجازې ته اړتیا نه لري، او هغه لېست چې مخکې لاسلیک شوی وي کېدای شي خپل انډیکس نیول شوی ومومي. او یوه سکه په Rand کې مخکې له دې لېست کېږي چې setToken یې د سرچینې پر پای‌ټکي فعاله کړي: که برعکس وي، یوه زېرمه کېدای شي مخکې له دې قفل شي چې Rand د کریډیټ لپاره ملاتړ ولري، او د هغې تصدیق به تر هغه UnlistedToken سره رد کېږي چې Rand ورسره برابر شي.

حکومتي پیغامونه

ټاکلي بایټونه، هېڅکله bincode نه؛ ټول بشپړ عددونه big-endian دي:

M_pause    = "rand-bridge-pause-1"        || chain_id u64 || nonce u64
M_unpause  = "rand-bridge-pq-unpause-1"   || chain_id u64 || nonce u64
M_list     = "rand-bridge-pq-list-1"      || chain_id u64 || nonce u64 || token_index u32 || chain u16 || token [32] || decimals u8
M_register = "rand-bridge-pq-register-1"  || chain_id u64 || nonce u64 || u8 len || name || u8 len || symbol || salt [32] || chain u16 || token [32] || decimals u8
M_rotate_pq    = "rand-bridge-pq-rotate-pq-1"    || chain_id u64 || rotation_nonce u64 || count u32 || key [1312] …   // rules v2
M_rotate_pause = "rand-bridge-pq-rotate-pause-1" || chain_id u64 || rotation_nonce u64 || key [1312]            // rules v2

M_pause/M_unpause له ځانه سره pause_nonce لري، M_list/M_register له ځانه سره list_nonce لري، او M_rotate_pq/M_rotate_pause له ځانه سره rotation_nonce لري. count د کیلیو شمېر دی، نه د بایټونو اوږدوالی؛ هره کیلي د Dilithium2 عامې کیلي خام 1,312 بایټه ده، په هغه ترتیب چې نوې ټولګه به یې ولري.

په chain 20 کې هر پیغام له genesis هش سره تړل شوی دی (genesis binding_domain: 1): د ټګ د نسخې شمېره 2 ته اوړي او 32 بایټه genesis هش د ټګ او chain id ترمنځ ځای نیسي، پاتې برخه نه بدلېږي: M'_pause = "rand-bridge-pause-2" || genesis [32] || chain_id u64 || nonce u64، او همداسې rand-bridge-pq-unpause-2، rand-bridge-pq-list-2، rand-bridge-pq-register-2، rand-bridge-pq-rotate-pq-2 او rand-bridge-pq-rotate-pause-2 (bridge/gov.rs). د ځنډولو کیلي یا کوورم چې د یوه chain لپاره لاسلیک وکړي، نو د بل هېڅ داسې chain لپاره لاسلیک نه کوي چې همغه chain id او همغه کیلي لري. هغه فایل چې په …-1 بڼه لاسلیک شوی وي په chain 20 کې ردېږي (BadPauseSignature، PqBadSignature). له chain 14 تر 19 پورې پورته …-1 جوړښتونه کاروي، بایټ په بایټ.

Rules v2: بدلونونه، ښوییدونکي سقفونه، د ځنډ پر مهال لېست نه کول

د genesis د bridge برخې دننه یوه اختیاري ډله. chain 14 دا نه درلوده؛ له 15 راهیسې هر chain یې لري، chain 20 هم له همغو ارزښتونو سره:

"bridge": { …, "rules_v2": { "global_mint_cap_per_window": 400000000000, "cap_window_secs": 86400 } }

• د پوسټ-کوانټم کوورم لاندې دوه بدلونونه. RotatePqGuardians { new_pq_guardians, nonce, pq_signatures } ټوله پوسټ-کوانټم ټولګه بدلوي؛ RotatePauseKey { new_pause_key, nonce, pq_signatures } د ځنډولو کیلي بدلوي. دواړه د PauseMints په څېر بې بنډله او بې فیسه دي، دواړه د اوسنۍ پوسټ-کوانټم ټولګې له خوا لاسلیکېږي، او دواړه rotation_nonce له ځانه سره لري او یو یې پورته کوي، نو یو لاسلیک شوی کوورم یوازې او یوازې یو بدلون اجازه کوي. نوې ټولګه باید د اوسنۍ ECDSA ټولګې اوږدوالی ولري، 1,312 بایټه کیلي ولري، تکرار ونه لري او د ځنډولو کیلي پکې نه وي. د مهلت کړکۍ نشته: بدله شوې ټولګه یا کیلي نور هېڅ شی نه لاسلیکوي. په chain 20 کې دا v1 کړنې ردېږي، او بدلون باید د نویو کیلیو د لرلو ثبوت وړاندې کړي او یوه ورځ انتظار وکړي (لاندې).
• د ښوییدونکې کړکۍ سقفونه. د هر ملاتړ mint_cap_per_day د تقویم د ورځې پر ځای د cap_window_secs په یوه ښوییدونکې کړکۍ کې اندازه کېږي، او دوهم سقف چې د ټول راجستر په کچه دی، global_mint_cap_per_window، د هر ټوکن ټول ملاتړونه یوځای پوښي (TokenError::GlobalMintCapExceeded). په chain 20 کې دا 400,000,000,000 واحدونه دي، 4,000 zUSD په هرو 86,400 s کې. د ورځې د قاعدې لاندې، په 23:59:59 کې سقف او بیا په 00:00:01 کې، په دوو ثانیو کې د سقف دوه برابره کېده؛ د کړکۍ لاندې دوهم ردېږي.
• د ځنډ پر مهال لېست نه کول. RegisterBridgedToken او ListBacking تر هغه چې mint_paused وي، له MintsPaused سره ردېږي. سوځول او دواړه بدلونونه پرانیستي پاتې کېږي.

بدلون: د لرلو ثبوت او د یوې ورځې ځنډ

Rules v2 درې شیان پرانیستي پرېښي وو: هېڅ شي دا نه ثابتوله چې نوې کیلي د چا په لاس کې دي (یوه ټایپي تېروتنه، یا داسې کیلي چې هېڅوک یې نه لري، به پوسټ-کوانټم کوورم د تل لپاره له کاره غورځاوه)، بدلون په همغه بلاک کې اغېز کاوه چې پکې ثبت شو، او هېڅ شي نشو کولی یو خصمانه بدلون ودروي. دوهمه اختیاري ډله د rules_v2 تر څنګ (چې دا ورته اړتیا لري)، چې په v0.6.8 کې نوې ده (audit v6، BRG-14)، دا تړي. chain 20 یې ټاکي:

"bridge": { …, "rotation": { "delay_secs": 86400, "needs_possession": true } }

• د لرلو ثبوت. بدلون باید RotatePqGuardiansV2 { new_pq_guardians, possession, nonce, pq_signatures } یا RotatePauseKeyV2 { new_pause_key, possession, nonce, pq_signatures } وي: possession[i] د نوې کیلي i خپل Dilithium2 لاسلیک دی پر همغه پیغام چې کوورم یې لاسلیکوي (M_rotate_pq یا M_rotate_pause، په chain 20 کې د هغو په …-2 بڼه)، د کیلیو په ترتیب د هرې کیلي لپاره یو، هر یو 2,420 بایټه. v1 کړنې له PossessionRequired سره ردېږي. ناسم شمېر یا اوږدوالی د کوورم له تاییدولو مخکې ردېږي؛ ناسم د لرلو لاسلیک (BadPossession { index }) له هغه وروسته.
• ځنډ. منل شوی بدلون د تعلیق شوي په توګه ثبتېږي، له effective_at_secs = block time + delay_secs سره، او د هغه لومړي بلاک په پای کې اغېز کوي چې مهال‌ټاپه یې دې ته ورسېږي. په chain 20 کې دا 86,400 s، یوه ورځ ده. تر هغه پورې زړه ټولګه هر منټ ګډ لاسلیکوي او د ځنډولو زړه کیلي ځنډ کوي. د بدلون منل یو rotation_nonce لګوي او فعالول یې بل، نو د منټ هغه تصدیق چې د زړې ټولګې لاندې په حوض کې راټول شوی وي، د ټولګې په بدلېدو سره له حوض څخه وځي. د هر ډول یو بدلون په یو وخت کې تعلیق کېدای شي (RotationPending { effective_at_secs }).
• لغوه کول. CancelRotation { kind, nonce, signature } (بې بنډله، بې فیسه) د kind تعلیق شوی بدلون غورځوي (0 = پوسټ-کوانټم ټولګه، 1 = د ځنډولو کیلي). دا د اوسنۍ د ځنډولو کیلي له خوا لاسلیکېږي، هغه یوازینۍ کیلي چې له کوورم څخه جلا ساتل کېږي، په chain 20 کې پر "rand-bridge-cancel-rotation-2" || genesis [32] || chain_id u64 || rotation_nonce u64 || kind u8، او نانس لګوي. له دې امله نیول شوی کوورم نشي کولی ټولګه له یوې ورځې په کمه موده کې بدله کړي، او د ځنډولو کیلي لرونکی کولی شي په همدې ورځ کې یې ودروي؛ راتلونکې د ځنډولو کیلي نشي کولی خپل راتګ لغوه کړي.

لاسلیکوونکی rand-node bridge-gov دی (rotate-pq، rotate-pause، cancel-rotation، هر یو له message، sign او submit ګامونو سره؛ submit له لېږلو مخکې د لرلو هره کرښه بیا تاییدوي). rand_getBridgeState، rotation_rules او pending_rotations وړاندې کوي؛ په هغه chain کې چې دا ډله نه لري (له chain 14 تر 19) دواړه null دي. د ECDSA ساتونکو د ټولګې بدلون (payload 2) اغېزمن نه دی: خپلې قاعدې او د مهلت کړکۍ ساتي. په chain 20 کې تر اوسه هېڅ بدلون نه دی ترسره شوی.

له chain 14 څخه راوړل شوي

chain 15 د chain 14 د پُل له حالت څخه (همغه خپرونکي او د سرچینې پای‌ټکي) جلا شو، او chains 16، 17 او 18 هر یو په همدې ډول د خپل مخکیني له حالت څخه جلا شول. chain 19 د chain 18 له حالت څخه له یوه بدلون سره جلا شو: د هغه Ethereum، BSC او Tron خپرونکي هغه پای‌ټکي دي چې په 2026-09-30 بیا ځای پر ځای شول (0x7af6b17047c1db6cb54347fdea45cf9179075bfa د chains 2 او 3 لپاره، 0x6410797df959987a5baf65b5fab97edeb34d5163 د chain 4 لپاره). chain 18 هېڅکله پر دوی باور نه درلود، نو هلته له دوی څخه هېڅ شی نه دی منټ شوی. chain 20 په 7,258 لوړوالي کې د chain 19 له یوه سنیپ‌شاټ څخه جلا شو، په داسې حال کې چې پُل لومړی ودرول شو، او د chain 19 خپرونکي، ساتونکي، پوسټ-کوانټم کیلي او د ځنډولو کیلي بې بدلونه ساتي؛ هغه څه چې ور زیاتوي یې د فیسونو او بدلون ډلې دي. د Solana خپرونکی او د Rand اړخ خپرونکی له chain 14 راهیسې نه دي بدل شوي. هغه څه چې د chain 20 genesis یې لري:

• امانت ساتنه. 99 zUSD، د پیدایښت د دوو zUSD نوټونو په بڼه (10 او 89 zUSD)، د Ethereum پر سر د 22 قفل شوو USDT، پر BSC د 22 USDT، پر Tron د 30 USDT او پر Solana د 25 USDT، او د USDC پر هره پشتوانه د 0 په وړاندې: دا د سنیپ‌شاټ پر مهال د chain 19 locked و، چې د پای ټکو له امانت ساتنې سره سمون درلود. total_supply == Σ locked په 0 بلاک کې د پای ټکو له امانت ساتنې سره برابر دی. تاریخچه: هغه 10 zUSD چې پر chain 14 پاتې وو، له chain 15 تر chain 19 پورې د پیدایښت یو نوټ و؛ د chain 18 پیدایښت هغه د Tron پر سر د 9 قفل شوو USDT او پر Solana د 1 په بڼه ساتل، او د chain 19 پیدایښت پر chain 18 د یوه بیا توازن وروسته پر Solana د 10 په بڼه. پاتې 89 د chain 19 خالص زېرمې دي، د هغه له سوځولو وروسته.
• د ساتونکو د ټولګې شمېره 1، چېرې چې د سرچینې پای ټکي لا دمخه دي؛ راتلونکی ECDSA بدلون باید شمېره 2 ولري. اته پوسټ‌کوانټم کیلي او د درولو کیلي د chain 15 دي، بې بدلونه.
• burn_sequence 13: د chain 14 سوځول په 6 پای ته ورسېدل، له chain 15 تر chain 18 پورې پیدایښت له 7 پیل شو، chain 18 یو سوځول وکړ (7) او chain 19 له 8 پیل شو. chain 19 پنځه سوځول وکړل، له 8 تر 12 پورې ترتیبونه، نو chain 20 له 13 پیلېږي، او هېڅ پای ټکی یا ډیمن چې د ترتیب له مخې کیلي لري، یو ترتیب دوه ځله نه ویني. د chain 20 لومړي سوځول 13 ترتیب واخیست.
• بیا لېږل. د یوه پخواني chain صادرول به لا هم د ECDSA نصاب تېر کړي، خو د هغه پوسټ‌کوانټم ګډ لاسلیک د هماغه chain پېژند پورې تړلی دی، نو پر chain 20 ردېږي. د chain 15 پیدایښت د راتلونکو لپاره د بیا لېږلو ښکته پوله نه درلوده (min_inbound_sequence null و)، نو هلته دا پر ګډ لاسلیک او پر دې ولاړه وه چې ساتونکي هېڅکله د نوي chain پېژند لپاره پر یوه زاړه قفل ګډ لاسلیک نه کوي. له chain 16 راهیسې پیدایښت یوه ټاکي: د هرې سرچینې chain لپاره، ټیټ‌ترین sequence چې د هغه chain د خپروونکي د لېږد تصدیق یې کولی شي ولري. د chain 20 پوله { "2": 3, "3": 3, "4": 3, "5": 7 } ده: د هر پای ټکي راتلونکی بهرنی ترتیب کله چې د chain 19 سنیپ‌شاټ واخیستل شو، او هر پخوانی قفل پر chain 19 صادر شوی و. (د chain 18 پوله { "2": 2, "3": 2, "4": 2, "5": 2 } وه؛ د chain 19 پوله { "2": 1, "3": 1, "4": 1, "5": 4 } وه، چېرې چې پر هر بیا ځای پر ځای شوي پای ټکي 0 ترتیب د چلوونکي خپل قفل و، چې باید هېڅکله صادر نه شي.) له پولې ښکته لېږد په BelowReplayFloor ردېږي، که هر نصاب او ګډ لاسلیک ولري. د ساتونکو د ټولګې بدلونونه د دې له مخې نه ارزول کېږي. پوله په پیدایښت کې ټاکل کېږي، د پیدایښت په هش پورې ژمنه کېږي او د bridge په ریښه کې نغښتل کېږي.

پر chain 14 د پیلولو ترتیب (تاریخچه)

bridge څنګه پر chain 14، چې یو پخوانی testnet و، د 2026 کال په سپتمبر کې پیل شو:

1. chain د bridge برخې (د pq_guardians او pause_key په ګډون) او د tokens برخې سره پرې کړئ چې registration_fee او mint_cap_per_day ټاکي او هېڅ ټوکن نه لړلیکوي. 2026-09-20 ترسره شو.
2. فاسېټ فعال کړئ څو د ځای پر ځای کوونکي والټ RAND ترلاسه کړي. ترسره شو.
3. ځای پر ځای کوونکی zUSD له خپلې لومړۍ پشتوانې سره د list_nonce = 0 پر مهال د M_register پر سر د نصاب تر لاسلیک لاندې ثبتوي. په 256 لوړوالي کې ترسره شو.
4. ساتونکي شمېره بېرته لولي او شپږ پاتې ListBacking پیغامونه لاسلیکوي، چې یو په یو سپارل کېږي. ترسره شو: list_nonce 7 لولي.
5. د هرې پشتوانې لپاره: د سرچینې پر پای ټکي له setToken دمخه پر Rand لړلیک کړئ.
6. د ساتونکو د ټولګې بدلون (ټولګه 0 → ټولګه 1، د اوسنۍ ټولګې له خوا له 6 څخه 5 لاسلیکونه) پر څلورو سرچینه پای ټکو، او بیا همدغه تصدیق پر Rand. Rand د chain 14 د ټول عمر لپاره ټولګه 0 لوستله؛ chain 15 له ټولګې 1 پیلېږي.
7. د هرې سرچینې chain لپاره له کوچنیو مقدارونو سره یو ژوندی بشپړ سفر — bridge ته ننوتل، د zUSD صادرول، لېږد، بېرته سوځول — او د هرې پشتوانې د locked (rand_getTokenSupply) پخلاینه د پای ټکي له امانت ساتنې سره.

عامه حالت

rand_getBridgeState:

{
  "enabled": true,
  "emitter": "01…",  "emitters": { "2": "02…" },
  "guardian_set_index": 0, "guardians": ["aabb…"],
  "pq_guardians": ["…"],
  "mint_paused": false, "pause_nonce": 0, "list_nonce": 0, "pause_key": "…",
  "registration_fee": "1000000000",
  "burn_sequence": 1,
  "rotation_nonce": 0,
  "rules_v2": { "global_mint_cap_per_window": "400000000000", "cap_window_secs": 86400,
                "global_minted_in_window": "…", "global_mint_headroom": "…" },
  "min_inbound_sequence": null,
  "rotation_rules": null, "pending_rotations": null,
  "fees": null,
  "assets": [ … ]
}

pq_guardians د Dilithium2 عامه کیلي دي، هره یوه 1,312 بایټه د hex په بڼه. نور next_index نشته: یو bridge شوی ټوکن د یوې داسې شمېرې لاندې لړلیک کېږي چې د هغه ثبت ټاکلې، مخکې له دې چې زېرمه شي، نو د وړاندوینې لپاره هېڅ شمېره نه پاتې کېږي. rotation_nonce هغه څه دي چې راتلونکی M_rotate_pq/M_rotate_pause/M_cancel باید ولري؛ rules_v2 پر هغه chain چې دا ډله نه لري (chain 14) null دی، او min_inbound_sequence پر هغه chain چې د بیا لېږلو ښکته پوله نه لري (chain 15 او تر هغه پخوا) null دی؛ پر chain 20 دا { "2": 3, "3": 3, "4": 3, "5": 7 } دی. rotation_rules، pending_rotations او fees پر هغه chain چې دا ډلې نه لري (له chain 14 تر chain 19 پورې) null دي. پورتنۍ بېلګه بڼه ښيي، نه د chain 20 ارزښتونه: chain 20 له guardian_set_index 1 او burn_sequence 13 سره پیل شو، او "rotation_rules": { "delay_secs": 86400, "needs_possession": true }، "pending_rotations": [] او "fees": { "mint_bps": 10, "burn_bps": 10, "recipient": "rand1…" } وړاندې کوي. هغه chain چې bridge برخه نه لري {"enabled": false} ځواب ورکوي.

هېڅ بیلانس نشته: bridge شوی ارزښت نوټونه دي، او والټ هغه څه چې لري د خپلو نوټونو څخه د rand asset-balance [INDEX] په مرسته لولي. د bridge ریښه خپروونکي، د ساتونکو ټولګې، لګول شوي ډایجسټونه، د سوځولو ترتیب، د پوسټ‌کوانټم ساتونکو ټولګه، او د درولو کیلي، د درولو بیرغ او د حکومتولۍ نانسونه (دوه، او د rules v2 لاندې rotation_nonce)، د بیا لېږلو ښکته پوله هلته چې پیدایښت یې ټاکي، او پر chain 20 د بدلون قواعد له هر پاتې بدلون او د فیس له ډلې سره ژمنه کوي؛ دا یوازې پر هغه chain کې چې bridge لري د حالت په ریښه کې نغښتل کېږي. د ټوکنونو ثبت، د هرې پشتوانې له locked سره، په جلا توګه د tokens_root په بڼه ژمنه کېږي. د explorer GET /bridge او GET /bridge/assets همدغه حالت وړاندې کوي، دویم یې د هرې پشتوانې د زېرمې او سوځولو ټولګه د 8-اعشاري تارونو په بڼه؛ GET /tokens او GET /tokens/:id ثبت وړاندې کوي.

څه عام دي او څه پټ

پېژندل شوې تشې

د fullnode د خپل لړلیک له مخې: پر Rand هېڅ رله کوونکي ته پیسې نه ورکول کېږي؛ د یوې زېرمې لفافه له هېڅ شي سره نه ده تړل شوې، نو یو دښمن رله کوونکی کولی شي بې‌ګټې معلومات مهر کړي، له همدې امله والټ د زېرمې نوټونه پر ځای یې له عامو ساحو څخه بیا جوړوي؛ د لېجر په کچه ګډ ازمېښتي وکټورونه لا پر نوټ حوض بیا نه دي جوړ شوي؛ bridge-burn لا هم د منزل پای ټکي د خپلې پالیسۍ په اړه یوازې د ثبوت د پیسو له ورکولو وروسته خبرېږي؛ پر یوه bridge شوي chain د بلاک هغه مهال‌ټاپې چې له مور بلاک سره برابرې وي اجازه لري، نو ګډ کار کوونکي مشران کولی شي یوه بدله شوې ساتونکو ټولګه د هغې د مهلت په کړکۍ کې وساتي؛ د حافظې دننه د سوځولو لاګ بې‌حده دی؛ د سرچینې chain د حالت لپاره هېڅ سپک مراجع یا پر chain تایید نشته او نه یې پلان شته.