பாலம்

இந்தப் பக்கத்தைக் கொண்டு பாலத்துடன் ஒருங்கிணைக்கலாம்: மூலச் சங்கிலியில் ஒரு வைப்பை உருவாக்க, Rand-இல் ஒரு சான்றளிப்பைச் சமர்ப்பிக்க, பாலம் வழி வந்த ஒரு சொத்தை எரித்து வெளியே அனுப்ப, பாலத்தின் பொது நிலையைப் படிக்க. தற்போதைய testnet ஆன Chain 20 (2026-10-01 06:17 UTC முதல் இயங்குகிறது, fullnode v0.6.8) ஒரு bridge பிரிவுடன் உருவாக்கப்பட்டது. அதில் உள்ளவை: காவலர் தொகுப்புக் குறியீடு 1-இல் தொடங்கும் எட்டுக் காவலர்கள், எட்டு குவாண்டத்துக்குப் பிந்தைய காவலர்கள், ஒரு இடைநிறுத்த விசை, Ethereum, BSC, Tron, Solana ஆகியவற்றுக்கான உமிழ்விகள் (முதல் மூன்றும் 2026-09-30 அன்று மீண்டும் நிறுவப்பட்ட முனைகள்), சுழலும் 24 மணி நேரத்துக்கு 4,000 zUSD என்ற உலகளாவிய அச்சிடல் உச்சவரம்பு கொண்ட rules-v2 குழு, உள்வரும் மறுபயன்பாட்டுக்கான கீழ்வரம்பு, v0.6.8-இல் புதிதாக வந்த இரண்டு குழுக்கள். அவற்றுள் முதலாவது கட்டணங்கள்: ஒவ்வொரு அச்சிடலுக்கும் ஒவ்வொரு எரித்தலுக்கும் 10 bps, zUSD-இல் வசூலிக்கப்படும். இரண்டாவது சுழற்சி விதிகள்: குவாண்டத்துக்குப் பிந்தைய தொகுப்பின் சுழற்சியோ இடைநிறுத்த விசையின் சுழற்சியோ புதிய விசைகள் தன்னிடம் உள்ளன என்பதை நிரூபித்து, ஒரு நாள் காத்திருக்க வேண்டும் என்று அவை விதிக்கின்றன. chain 14-இன் தொடக்கத் தொகுதியைப் போலன்றி, இதன் தொடக்கத் தொகுதி zUSD-ஐ அதன் ஏழு பிணையங்களுடனும் பட்டியலிடுகிறது. chain 14 முதல் ஒவ்வொரு புதிய சங்கிலி உருவாக்கத்திலும் தொடர்ந்து வந்த காப்புப் பொறுப்பையும் இது தொடர்கிறது (chain 14-இலிருந்து தொடர்ந்து வந்தவை). ஒவ்வொரு பிணையத்தின் தற்போதைய locked மதிப்பை rand_getAssets, explorer-இன் /bridge/assets ஆகிய இரண்டும் தருகின்றன.

செயல்முறை

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. ஒவ்வொரு கையொப்பமும் low-s ஆக (s ≤ n/2) இருக்க வேண்டும். இது கையொப்ப மாற்றியமைப்புக்கு (malleability) இடம் தருவதில்லை. காவலர்கள் கையொப்பமிடும் சுருக்கம் mu = keccak256(keccak256(body_bytes)). காவலர் தொகுப்புச் சுழற்சி என்பது ஆளுகை உமிழ்வியான (chain 1, keccak256("rand-bridge-governance"))-இடமிருந்து வரும் ஒரு சான்றளிப்பு. அது new_index == current + 1 என்பதைக் கொண்டிருக்க வேண்டும். மாற்றப்பட்ட பழைய தொகுப்பு அல்ல, தற்போதைய தொகுப்பே அதில் கையொப்பமிட வேண்டும். பரிமாற்றத்தில் உள்ள இடமாற்றங்களுக்காக, வெளியேறும் தொகுப்புக்கு 86,400 விநாடிச் சலுகைக் காலம் உண்டு. (இது ECDSA தொகுப்பு பற்றியது. குவாண்டத்துக்குப் பிந்தைய தொகுப்பும் இடைநிறுத்த விசையும் அவற்றுக்கே உரிய செயல்களால் சுழல்கின்றன. chain 20-இல் அவை ஒரு நாள் தாமதத்துக்குக் காத்திருக்கின்றன: கீழே.) n·2/3 + 1 காவலர்கள் கூட்டுச் சேர்ந்தால் அவர்களால் எந்த மதிப்பையும் அச்சிட முடியும். அவர்களால் எவ்வளவு, எவ்வளவு வேகமாக அச்சிட முடியும் என்பதற்கு பால வலுப்படுத்தல் வரம்பிடுகிறது. ஆனால் அந்த அபாயத்தை அது நீக்குவதில்லை.

பரிவர்த்தனைப் பிணைப்பு. ஒரு Rand பரிவர்த்தனை எந்தக் கையொப்பத்தையும் கொண்டிருப்பதில்லை. ஓர் எரித்தல் அதன் தொகுப்பின் STARK நிரூபணத்தால் அங்கீகரிக்கப்படுகிறது. chain 14 முதல், ஒவ்வொரு தொகுப்பு நிரூபணமும் Transaction::binding-இன் மீது உருவாக்கப்பட்டு, அதற்கு எதிராகவே சரிபார்க்கப்படுகிறது. அது முழுப் பரிவர்த்தனையின் (சங்கிலி அடையாளம், நான்கு உறைகளுடன் கூடிய ஒரே தொகுப்பு, செயல்) ஹாஷ். அதில் நிரூபணப் பைட்டுகள் மட்டும் வெறுமையாக்கப்படுகின்றன. chain 17 முதல் ஒரு தொகுப்பு இரண்டு நிரூபணங்களைக் கொண்டுள்ளது: தொகுப்பு நிரூபணம், செலவு அங்கீகார நிரூபணம். பிணைப்பு இரண்டையும் வெறுமையாக்குகிறது, தொகுப்பின் auth_commit-ஐத் தக்கவைக்கிறது, இரண்டு நிரூபணங்களும் அதற்கு எதிராகச் சரிபார்க்கப்படுகின்றன. நிலுவையில் உள்ள ஓர் எரித்தலின் நகலில் to, relayer_fee அல்லது (to_chain, token) மாற்றப்பட்டால், அல்லது ஒரு சான்றளிப்பின் நகலில் அதன் time அல்லது உறை மாற்றப்பட்டால், நிரூபணம் தோல்வியடைகிறது (TxError::InvalidBundleProof). chain 20-இல் பிணைப்பு தொடக்கத் தொகுதியின் ஹாஷையும் கொண்டுள்ளது (தொடக்கத் தொகுதியில் binding_domain: 1: தொடக்கத் தொகுதி ஹாஷ், சங்கிலி அடையாளம், தொகுப்பு, செயல் ஆகியவற்றின் மீதான rand-tx-bind-2). ஆகவே அதே சங்கிலி அடையாளத்தைப் பகிரும் வேறொரு சங்கிலிக்காக உருவாக்கப்பட்ட நிரூபணமும் சரிபார்க்கப்படாது. வாலட்களும் ரிலேயர்களும் தாங்கள் சமர்ப்பிக்கும் சங்கிலிக்காகக் கட்டமைக்கப்பட்ட பைனரியையே இயக்க வேண்டும்: chain 20-க்கு v0.6.8 (chains 18, 19-க்கு v0.6.7). பழைய rand உருவாக்கும் நிரூபணங்களையும் கையொப்பங்களையும் chain 20 நிராகரிக்கிறது.

காவலர், ரிலேயர் டீமன்கள் முழு முனையின் பகுதி அல்ல. பகிரப்பட்ட கோடெக்கையும் பெறும் பகுதியையும் மட்டுமே முழு முனை கொண்டுள்ளது.

கம்பி வடிவம்

ஒவ்வொரு முழு எண்ணும் big-endian. கம்பிப் பதிப்பு 1.

சான்றளிப்பு உறை

உடல் தலைப்பு: 51 பைட்டுகள், அதன் பின் சுமை

Transfer சுமை: id 1, 133 பைட்டுகள்

GuardianSetUpgrade சுமை: id 2: id (1), new_index (4), n (1), அதன் பின் 20 பைட் அளவுள்ள n விசைகள்.

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 செயலில் முழு முகவரியை இடுகிறார். பேரேடு ஹாஷை மீண்டும் கணக்கிட்டு, பொருந்தாவிட்டால் நிராகரிக்கிறது. இல்லையெனில் வேறொருவரின் வைப்பை யார் பெற வேண்டும் என்பதைச் சமர்ப்பிப்பவரே தேர்ந்தெடுக்க முடியும். மூலச் சங்கிலி முன்முனைகள் இந்த வடிவத்தை ஏற்க வேண்டும். வாலட் இதை அச்சிட்டுக் காட்டுகிறது. Chain 11 சிறிது காலம் அந்த இடத்தில் நேரடியாகப் பெறுநர் அடையாளத்தை வைத்தது. அந்த முகவரி வடிவம் chain 12-இல் திரும்பப் பெறப்பட்டது (கணக்குகளும் முகவரிகளும்).

ஒரு டோக்கன், பல பிணையங்கள்: zUSD

சொத்துப் பதிவேடு இப்போது பாலத்துக்கு உரியதல்ல. அது பேரேட்டு நிலையில் உள்ள RPL டோக்கன் பதிவேட்டுக்கு மாற்றப்பட்டது. அந்தப் பதிவேடு சொந்த டோக்கன்களுக்கும் பாலம் வழி வந்த டோக்கன்களுக்கும் பொதுவானது. சங்கிலியின் நிலை வேர் அதை tokens_root ஆக உறுதிப்படுத்துகிறது. பாலம் வழி வந்த டோக்கன் என்பது அச்சிடல் அதிகாரம் Bridge { backings } ஆக உள்ள ஒரு பதிவேட்டு உள்ளீடு. அது இனி ஒரே ஒரு (chain, token) இணைக்கு ஒத்ததல்ல. இவற்றுள் முதலாவது zUSD. நான்கு சங்கிலிகளில் பூட்டப்பட்ட USDT, USDC ஆகியவை அதற்குப் பிணையமாக உள்ளன. Ethereum, Binance Smart Chain, Solana ஆகியவற்றில் இரண்டு நாணயங்களும் உள்ளன, Tron-இல் USDT மட்டுமே உள்ளது (Tron-இல் USDC-ஐ Circle நிறுத்திவிட்டது):

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

chain 20-இல் zUSD-இன் விவரங்கள்: குறியீடு 1, rpl1xtj6k2x8strx8c2d5fjs50ltztck5ykms4ve7nmzmstf6fhn0v0spelqtx, பெயர் “Shielded USD”, 8 தசம இடங்கள். chains 15 முதல் 19 வரை இருந்ததைப் போலவே இது தொடக்கக் கோப்பில் பட்டியலிடப்பட்டுள்ளது. chain 14-இல் இருந்த அதே பெயர், குறியீடு, salt ஆகியவையே இதற்கும் உள்ளன. ஆகவே அதன் சொத்து அடையாளமும் (32e5ab28c782c663e14da2650a3feb12f16a12db85599f4f62dc169d26f37b1f) rpl1… அடையாளமும் மாறாமல் தொடர்கின்றன (explorer: GET /tokens/1). chain 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 வைத்திருப்பவரின் மதிப்பையும் குறைக்கும். ஒரு பிணையத்தின் பங்குக்கு Rand பக்கத்தில் எந்த உச்சவரம்பும் இல்லை.

zUSD ஒரு கூடை. வைத்திருப்பவர், தாம் வைப்புச் செய்த நாணயத்தின் இடரை மட்டுமன்றி, பட்டியலிடப்பட்ட ஒவ்வொரு ஆதாரச் சொத்தின் இடரையும் தாங்குகிறார்: ஒரு zUSD என்பது குளத்தின் மீதான உரிமை; போதுமான locked உள்ள எந்த ஆதாரச் சொத்தின் மீதும் அது செல்லும். எந்த ஆதாரச் சொத்துக்கும் விலை நிர்ணயிக்கப்படுவதில்லை. பட்டியலிடப்பட்ட எந்த நாணயத்தின் 1 அலகைப் பூட்டினாலும் 1 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-இல், விடுவிப்பின்போது முனைகள் தாமே எடுத்துவந்த 10 bps USDT கழிவு, பிரிப்பின்போது 0 என அமைக்கப்பட்டது; கட்டணம் இப்போது Rand-இல் எடுக்கப்படுகிறது.

வயரில் தொகைகள் 8-தசம அலகுகளில் உள்ளன, மூல நாணயத்தின் சொந்தத் தசம இடங்கள் எதுவாயினும்: Ethereum-இலிருந்து (6 தசம இடங்கள்) 1 USDT வைப்பு 100_000_000 அலகுகளாகப் பூட்டப்படுகிறது. சுட்டெண் 0 ஆன RAND மட்டுமே இந்தச் சங்கிலியின் ஒன்பது தசம இடங்களைக் கொண்டது.

ஒரு டோக்கன் அதன் முதல் வைப்புக்கு முன் பட்டியலிடப்பட வேண்டும். முதல் சந்திப்பிலேயே பதிவு செய்யும் முறை இனி இல்லை: யாரும் பட்டியலிடாத (chain, token)-ஐக் குறிப்பிடும் சான்றளிப்பு BridgeError::UnlistedToken (token … of chain … is not listed on this chain) என மறுக்கப்படுகிறது. ஒரு குவாண்டம்-பிந்தைய காவலர் குறைவெண் அந்த நாணயத்தைப் பட்டியலிடும் வரை நிதி மூலச் சங்கிலி முனையின் காப்பிலேயே இருக்கும் (மூலத்தொகுதிக்குப் பின் பட்டியலிடல்).

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 ஆகியவை 8-தசம அலகுகளிலான தசம எழுத்துச்சரங்கள்; chain 14 முதல் RPC வழங்கும் ஒவ்வொரு u64 தொகையும் இவ்வாறே. index, chain, decimals, mint_day எண்களாகவே இருக்கின்றன. டோக்கன் நிலை முறைகள் — rand_getTokens, rand_getToken, rand_getTokenSupply — பாலம் வழியான ஒரு டோக்கனை, அதன் எல்லா ஆதாரச் சொத்துகளையும் கொண்ட ஒரே வரிசையாகத் திருப்புகின்றன (RPL டோக்கன்கள்). எக்ஸ்ப்ளோரரின் 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 ஒரு தொகுப்பின் time-க்கு உள்ள அதே சாளரத்துக்குள் இருக்க வேண்டும் (chain 20-இல் 1,024 தொகுதிகள், மூலத்தொகுதியின் proof_window_blocks-இலிருந்து; முன்பு 256). அது வேண்டுமென்றே வருவிக்கப்படுவதில்லை: சமர்ப்பிக்கும் அனைவரும் ஒப்புக்கொள்ளும் time-ஐ எந்த விதியும் தருவதில்லை. ஆகவே ஒரு முன்னோட்டி சாளரத்துக்குள் வேறு time-ஐத் தேர்ந்தெடுக்கலாம் — அதே பெறுநர், தொகை, சொத்து கொண்ட வேறொரு நோட்டு; பெறுநரின் பணப்பை அதையும் அதே வழியில் கண்டறிகிறது — அப்போது இரு சமர்ப்பிப்புகளும் சான்றளிப்புச் சுருக்க மதிப்பில் மோதுகின்றன. asset என்பது பதிவேடு ஏற்கெனவே (chain, token)-க்கு வழங்கிய சுட்டெண்ணுக்குச் சமமாக இருக்க வேண்டும்; இல்லையெனில் TxError::AttestAssetMismatch.

Transfer தரவுச்சுமையின் fee கொண்டுசெல்லப்படுகிறது, ஆனால் யாருக்கும் செலுத்தப்படுவதில்லை: செலுத்துவதற்குச் சமர்ப்பிப்பவர் அடையாளம் எதுவும் இல்லை; ஆகவே வைப்பு மொத்தத் தொகையாகும், மூலத்தொகுதி அமைக்கும் இடத்தில் (chain 20) சங்கிலியின் சொந்த அச்சிடல் கட்டணம் மட்டுமே கழிக்கப்படுகிறது. மறுபயன்பாட்டுப் பாதுகாப்பு சுருக்க மதிப்பின் மூலம்: நுகரப்பட்ட ஒவ்வொரு mu-உம் பாலத்தின் spent தொகுப்பில் சேர்கிறது; அதே சான்றளிப்புக்காகப் போட்டியிடும் இரண்டாவது ரிலேயரை மெம்பூல் மறுக்கிறது. ஒரு வைப்பு ஆதாரச் சொத்தின் அச்சிடல் வரம்புக்கும், chain 20-இல் உலகளாவிய வரம்புக்கும் உட்பட்டது; அச்சிடல்கள் இடைநிறுத்தப்பட்டிருக்கும்போது மறுக்கப்படுகிறது (B1, rules v2). இரு வரம்புகளும் மொத்தத் தொகையையே கணக்கிடுகின்றன. மூலத்தொகுதி மறுபயன்பாட்டுத் தளத்தை அமைக்கும் சங்கிலியில் (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) அலகுகளில் விடுவிக்கிறது (6-தசம நாணயத்துக்கு 100; 18-தசம நாணயத்துக்கு 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 சரியான வடிவில் இருக்க வேண்டும் (சங்கிலிகள் 2, 3, 4-இல் பூச்சியத்தால் நிரப்பப்பட்ட 20 பைட்டுகள்; ஒருபோதும் முழுவதும் பூச்சியமாக இருக்கக்கூடாது). பேரேடு கண்டிப்பாக ஏறுமுகமான burn_sequence-இன் கீழ் ஒரு BridgeBurnRecord-ஐப் பதிவுசெய்கிறது, அனுப்புநர் இடத்தில் பரிவர்த்தனை ஹாஷுடன்; காவலர்கள் எரிப்புப் பதிவைப் படிக்கின்றனர்:

→ {"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 என்பது காவலர்கள் hash செய்து கையொப்பமிட வேண்டிய வெளிச்செல்லும் செய்தி, அப்படியே உள்ளது. அதன் Transfer தொகை release_amount ஆகும். மேலே உள்ள பதிவு சங்கிலி 20-இன் முதல் எரிப்பு ஆகும். உயரம் 2,899-இல் BSC USDT நோக்கி 0.999 zUSD எரிக்கப்பட்டது. அதில் 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

எந்த நிரூபணத்துக்கும் முன்பு, பால நிலையையும் டோக்கன் பதிவேட்டையும் ஒருமுறை படித்து, wallet சில சரிபார்ப்புகளைச் செய்கிறது. சங்கிலியில் பாலம் உள்ளதா, ASSET பதிவேட்டில் உள்ளதா, TO_CHAIN-இல் உள்ள TOKEN அதற்கு ஆதரவு இருப்பாக இருந்து குறைந்தது AMOUNT அளவு பூட்டப்பட்டுள்ளதா, AMOUNT-உம் ரிலேயர் கட்டணமும் முழு விடுவிப்பு அலகுகளா என்பவையே அவை. கட்டணங்கள் உள்ள சங்கிலியில், அதன் பின் wallet பாலக் கட்டணத்தையும் விடுவிக்கப்படும் தொகையையும் அச்சிட்டு, நிரூபணத்துக்கு முன் உறுதிப்படுத்தல் கேட்கிறது (--yes அந்தக் கேள்வியைத் தவிர்க்கிறது). அதன் பின் ஓர் எரிப்பு ஒரு bundle-ஐ நிரூபிக்கிறது. இதற்கு மடிக்கணினியில் சுமார் 100 s ஆகும், நிரூபணம் சுமார் 1.5 MB இருக்கும். சங்கிலி 17 முதல் ஒவ்வொரு bundle-க்கும் உள்ளது போலவே, சங்கிலி 20-இலும் அதனுடன் ஒரு செலவு-அங்கீகார நிரூபணம் இருக்கும் (சில வினாடிகள், சுமார் 1.37 MB).

அச்சிடல் மற்றும் எரிப்பின் மீதான கட்டணங்கள்

fullnode v0.6.8-இல் புதியது; சங்கிலி 20-இல் ஜெனிசிஸ் குழுவால் அமைக்கப்பட்டது

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

பாலம் வழியான ஒவ்வோர் அச்சிடலுக்கும் ஒவ்வோர் எரிப்புக்கும் சங்கிலி ஒரு கட்டணம் வசூலிக்கிறது. அது பாலம் வழியான டோக்கனிலேயே, 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 ஆகும். யாராவது அதை எரிக்கும் வரை அதன் மதிப்பு மூலச் சங்கிலியில் பூட்டியே இருக்கும். ஓர் எரிப்பு தன் RAND இடங்களில் செலுத்தும் 0.01 RAND ஆன BRIDGE_BURN_FEE மாறவில்லை, அது தனியானது.

node-இலிருந்து படிக்கப்பட்ட சங்கிலி 20-இன் முதல் இருவழிப் பயணம் இது. உயரம் 1,664-இல் BSC-இலிருந்து 1 zUSD வைப்பு (4f6e6c54…1a64) வைப்பாளருக்கு 0.999 zUSD-ஐயும் கருவூலத்துக்கு 0.001-ஐயும் தந்தது. உயரம் 2,899-இல் (வரிசை 13) BSC USDT-க்குத் திரும்ப 0.999 zUSD எரிப்பு 0.000999 zUSD-ஐ வைத்துக்கொண்டு 0.998001-ஐ விடுவித்தது. அதன் பின் (2026-10-01 அன்று படிக்கப்பட்டது) BSC USDT ஆதரவு இருப்பு 22.001999 zUSD கொண்டிருந்தது. டோக்கனின் வழங்கல் 99.001999 zUSD, அதன் ஆதரவு இருப்புகளின் கூட்டுத்தொகைக்குச் சமமாக இருந்தது.

கருவூலம் தன் குறிப்புகளை எவ்வாறு கண்டறிகிறது. கட்டணக் குறிப்புக்கு உறை இல்லை, அதன் ஒவ்வொரு கூறும் பொதுவானது. தொகை பரிவர்த்தனையிலிருந்தும் ஜெனிசிஸ் விகிதத்திலிருந்தும் வருகிறது. சொத்தும் time-உம் பரிவர்த்தனையிலிருந்து வருகின்றன. மறைப்புக் காரணி வருவிக்கப்படுகிறது. உரிமையாளர் ஜெனிசிஸ் recipient ஆகும். முகவரி recipient ஆக உள்ள wallet, வைப்புக் குறிப்புகளை மீளுருவாக்கும் அதே பொதுச் சுற்றில் கட்டணக் குறிப்புகளையும் மீளுருவாக்குகிறது. ஒவ்வோர் ஒத்திசைவிலும் அது rand_getBridgeState.fees-ஐயும் ஆதரவு இருப்புகளின் தசம இலக்கங்களையும் ஒருமுறை படிக்கிறது. கட்டணங்கள் குறித்துப் பொய் சொல்லும் node ஒரு குறிப்பைக் கண்டறியப்படாமல் செய்ய மட்டுமே முடியும், ஒருபோதும் ஒன்றை வரவு வைக்க முடியாது. வைப்பாளரின் wallet-உம் தன் சொந்த வைப்பை இதே முறையில், மொத்தத்திலிருந்து கட்டணத்தைக் கழித்து மதிப்பிடுகிறது. v0.6.8 wallet மட்டுமே இதைச் செய்கிறது. பழைய wallet எப்படியும் சங்கிலி 20-இல் அனுப்ப முடியாது.

குழு இல்லாத சங்கிலிகள் 14 முதல் 19 வரை கட்டணம் இல்லை. அங்கு வைப்பு மொத்தத்தை வரவு வைக்கிறது, எரிப்பு amount-ஐ விடுவிக்கிறது. சங்கிலி 20 வரை, ஒரே பாலக் கட்டணம் மூல endpoint-கள் விடுவிப்பின்போது புரவலர் சங்கிலியில் USDT-இலிருந்து தாமே எடுத்த 10 bps பிடித்தம் மட்டுமே. சங்கிலி 20-இன் வெட்டில் அது 0 ஆக அமைக்கப்பட்டது. குழு ஜெனிசிஸ் hash-க்கு உறுதிசெய்யப்பட்டு, rand-bridge-fees-1-இன் கீழ் பால root-இல் இணைக்கப்படுகிறது. குறியாக்க வடிவம் fullnode docs/bridge.md §25-இல் உள்ளது.

பால வலுப்படுத்தல்

ஒவ்வோர் ஆதரவு இருப்புக்குமான locked-உம் InsufficientBacking-உம் மீட்பைக் காக்கின்றன. அவை அச்சிடலை வரம்புக்குள் வைப்பதில்லை: செல்லுபடியான காவலர் கோரம் கொண்ட ஒரு சான்றளிப்பு, அது கூறுவதை அச்சிடுகிறது. மூன்று அடுக்குகள் அந்த இடைவெளியை மூடுகின்றன. நான்காவது அடுக்கு, சங்கிலி வெட்டு இல்லாமலே ஒரு டோக்கனைப் பட்டியலிட அனுமதிக்கிறது. இவற்றில் எதுவும் மூலச் சங்கிலி endpoint-களையோ, சான்றளிப்பு wire வடிவத்தையோ, bridge-codec-ஐயோ மாற்றுவதில்லை.

B1: ஒவ்வோர் ஆதரவு இருப்புக்கும் ஓர் அச்சிடல் வரம்பு, மற்றும் ஓர் அச்சிடல் இடைநிறுத்தம்

ஜெனிசிஸ் tokens.mint_cap_per_day ஒவ்வோர் ஆதரவு இருப்புக்கும் தனித்தனியாகப் பொருந்துகிறது. சங்கிலி 14 முதல் ஒவ்வொரு சங்கிலியும் செய்தது போலவே, சங்கிலி 20 10000000000000, அதாவது ஒவ்வோர் ஆதரவு இருப்புக்கும் ஒரு நாளுக்கு 100,000 zUSD என அமைக்கிறது. விதிகள் 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 காவலரிடமிருந்தும் வேறுபட்டது. bundle இல்லாத, கட்டணம் இல்லாத இரண்டு செயல்கள் உள்ளன:

• 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]

இடைநிறுத்தம் எதை உள்ளடக்குகிறது: post-quantum கோரத்தின் வைத்திருப்பவர்கள் ஏமாற்றப்படாத, சமரசம் செய்யப்படாத நிலையில், காவலர் daemon-கள் ஏமாற்றப்பட்டோ சமரசம் செய்யப்பட்டோ போலியான அச்சிடலுக்கு இணைக் கையொப்பமிடும் நிலை. அந்தக் கோரம் திருடப்படுவதற்கு எதிரான பாதுகாப்பு இது அல்ல. அத்தகைய கோரம் இடைநிறுத்தத்தை நீக்கலாம். ஒரே டோக்கனில் தலா சொந்த தினசரி வரம்புடன் 32 ஆதரவு இருப்புகள் வரை பட்டியலிடலாம். விதிகள் v2-இன் கீழ் post-quantum தொகுப்பையும் இடைநிறுத்த விசையையும் மாற்றலாம்.

B2: வரம்புக்குட்பட்ட தொகுதி நேரமுத்திரைகள்

பாலம் கொண்ட சங்கிலியின் தொகுதி நேரமுத்திரை காவலர்-தொகுப்புக் காலாவதியையும் அச்சிடல்-வரம்பு நாளையும் தீர்மானிக்கிறது. எனவே ஒரு தலைவர் அதைத் தாவச் செய்ய முடியக் கூடாது. பாலம் கொண்ட சங்கிலியில்:

• ஒரு செல்லுபடி விதி, மீள் இயக்கத்தின்போதும் சரிபார்க்கப்படுகிறது: timestamp_ms ≤ parent.timestamp_ms + 60_000, இல்லையெனில் BlockError::TimestampLeap. ஏற்கனவே உள்ள பின்னோக்கல் விதியுடன் (BlockError::TimestampRewind) சேர்ந்து, தொகுதி நேரம் முன்னோக்கி மட்டுமே நகரும், ஒரு தொகுதிக்கு அதிகபட்சம் ஒரு நிமிடம்.
• ஒரு வாக்கு விதி, ஒருபோதும் மீள் இயக்க விதி அல்ல: தன் சொந்தக் கடிகாரத்தைவிட 15,000 ms-க்கு மேல் முன்னால் உள்ள தொகுதிக்கு ஒரு சரிபார்ப்பாளர் தன் வாக்கை அளிப்பதில்லை.

எனவே பாலம் கொண்ட சங்கிலியில் ஒவ்வொரு சரிபார்ப்பாளருக்கும் 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 கோரம் கையொப்பமிடும் digest ஆகும். சங்கிலி அடையாளம், 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-இல் ஆறு இருந்தன, ஐந்து தேவைப்பட்டன).

இந்த இணைக்கையொப்பம் சங்கிலி 20-இலும் சங்கிலி அடையாள எண்ணை மட்டுமே இன்னும் பிணைக்கிறது: கீழே உள்ள ஆளுகைச் செய்திகளைப் போல் இது தோற்ற ஹாஷின் பின்னால் நகர்த்தப்படவில்லை, ஏனெனில் இதை உருவாக்கும் காவலர் டீமன்கள் வேறொரு களஞ்சியத்தில் உள்ளன, அவை மாற்றப்படவில்லை. காவலர் தொகுப்பையும் நகலெடுத்த, அதே அடையாள எண் கொண்ட ஒரு சங்கிலி நகல், மூலச் சங்கிலிக்காக உருவாக்கப்பட்ட ஒரு வைப்பின் இணைக்கையொப்பங்களை ஏற்றுக்கொள்ளும்; சங்கிலி 20-இல் வைப்புப் பரிவர்த்தனையின் சொந்தக் கட்டணத் தொகுப்பு தோற்றத்துடன் பிணைக்கப்பட்டுள்ளது, ஆனால் அதனுள் உள்ள சான்றுரை பிணைக்கப்படவில்லை.

B4: தோற்றத்திற்குப் பின் ஒரு பாலம்வழி டோக்கனைப் பட்டியலிடுதல்

ஒரு சாதாரண முகவரியால் ஒருபோதும் Bridge-அதிகார டோக்கனை உருவாக்க முடியாது. இரண்டு செயல்கள் உள்ளன; ஒவ்வொன்றும் ஒரு சாதாரண RAND கட்டணத் தொகுப்பின் மீதும், குவாண்டம்-பிந்தைய குறைவெண்ணின் கீழும் இயங்குகிறது:

• RegisterBridgedToken { name, symbol, salt, chain, token, decimals, nonce, pq_signatures } — அடுத்த குறியீட்டெண்ணில் ஒரு புதிய பாலம்வழி டோக்கன்; Rand-இல் 8 தசம இடங்கள், தோற்ற அச்சிடல் உச்சவரம்பின் கீழ், அதன் முதல் ஆதாரத்துடன். கட்டணம்: தொகுப்பின் அடிப்படைக் கட்டணமும் பதிவேட்டின் registration_fee-உம் (சங்கிலி 20-இல் 1 RAND, எனவே 1.001 RAND; சங்கிலி 20 பதிவுக் கட்டணத்தை முன்மொழிபவருக்குச் செலுத்தாமல் எரிக்கிறது).
• ListBacking { token_index, chain, token, decimals, nonce, pq_signatures } — ஏற்கெனவே பதிவுசெய்யப்பட்ட பாலம்வழி டோக்கனுக்கு locked = 0-இலிருந்து தொடங்கும் கூடுதல் ஆதாரம். கட்டணம்: தொகுப்பின் அடிப்படைக் கட்டணம்.

இரண்டும் list_nonce-ஐ எடுத்துச் சென்று ஒன்று உயர்த்துகின்றன (இல்லையெனில் BadListNonce { expected, got }), ஒரே சரிபார்ப்புகளை நடத்துகின்றன: அந்தச் சங்கிலிக்குப் பதிவுசெய்யப்பட்ட உமிழி உள்ளது (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>

இரண்டு வரிசைமுறை விதிகள் உள்ளன. காவலர்கள் முதலில் பதிவில் கையொப்பமிட்டு, அது உறுதிசெய்யப்படும் வரை காத்திருந்து, ஒதுக்கப்பட்ட குறியீட்டெண்ணைத் திரும்பப் படித்த பின்னரே அதைக் குறிப்பிடும் பட்டியலிடல்களில் கையொப்பமிடுகின்றனர் — சொந்த டோக்கனைப் பதிவுசெய்வதற்கு அனுமதி தேவையில்லை, எனவே முன்கூட்டியே கையொப்பமிட்ட பட்டியலிடலின் குறியீட்டெண் ஏற்கெனவே எடுக்கப்பட்டிருக்கக்கூடும். மேலும், மூல முனையத்தில் setToken ஒரு நாணயத்தை இயக்குவதற்கு முன்பே அது Rand-இல் பட்டியலிடப்படுகிறது: வரிசை மாறினால், வரவு வைக்க Rand-இல் ஆதாரம் இல்லாதபோதே ஒரு வைப்பு பூட்டப்படலாம், Rand அதைப் பிடிக்கும் வரை அதன் சான்றுரை UnlistedToken எனக் கூறி மறுக்கப்படும்.

ஆளுகைச் செய்திகள்

நிலையான பைட்டுகள், ஒருபோதும் bincode அல்ல; எல்லா முழு எண்களும் பெரு-முனை வரிசையில்:

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 பைட்டுகள், புதிய தொகுப்பில் அவை இருக்கப்போகும் வரிசையில்.

சங்கிலி 20-இல் ஒவ்வொரு செய்தியும் தோற்ற ஹாஷுடன் பிணைக்கப்பட்டுள்ளது (தோற்றம் binding_domain: 1): குறிச்சொல்லின் பதிப்பு இலக்கம் 2 ஆகிறது, 32-பைட் தோற்ற ஹாஷ் குறிச்சொல்லுக்கும் சங்கிலி அடையாள எண்ணுக்கும் இடையில் அமர்கிறது, மீதிப் பகுதி மாறவில்லை — 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). இதனால் ஒரு சங்கிலிக்காகக் கையொப்பமிடும் இடைநிறுத்தச் சாவியோ குறைவெண்ணோ, அதே சங்கிலி அடையாள எண்ணையும் அதே சாவிகளையும் பகிரும் வேறு எந்தச் சங்கிலிக்கும் கையொப்பமிடுவதாகாது. …-1 வடிவில் கையொப்பமிடப்பட்ட கோப்பு சங்கிலி 20-இல் மறுக்கப்படுகிறது (BadPauseSignature, PqBadSignature). சங்கிலிகள் 14 முதல் 19 வரை மேலே உள்ள …-1 அமைப்புகளையே பைட்டுக்குப் பைட் பயன்படுத்துகின்றன.

விதிகள் v2: சுழற்சிகள், நகரும் உச்சவரம்புகள், இடைநிறுத்தத்தின்போது பட்டியலிடல் இல்லை

தோற்றக் கோப்பின் bridge பிரிவினுள் உள்ள விருப்பத்தேர்வுக் குழு. சங்கிலி 14-இல் இது இல்லை; சங்கிலி 15 முதல் ஒவ்வொரு சங்கிலியிலும் உள்ளது, சங்கிலி 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 பைட்டுகளாக இருக்க வேண்டும், மீண்டும் வரக்கூடாது, இடைநிறுத்தச் சாவியாக இருக்கக்கூடாது. சலுகைக் காலம் இல்லை: மாற்றப்பட்ட தொகுப்போ சாவியோ அதன் பின் எதிலும் கையொப்பமிடாது. சங்கிலி 20-இல் இந்த v1 செயல்கள் மறுக்கப்படுகின்றன; ஒரு சுழற்சி புதிய சாவிகளை வைத்திருப்பதை நிரூபித்து ஒரு நாள் காத்திருக்க வேண்டும் (கீழே).
• நகரும்-சாளர உச்சவரம்புகள். ஒவ்வொரு ஆதாரத்துக்குமான mint_cap_per_day நாள்காட்டி நாளுக்குப் பதிலாக cap_window_secs அளவிலான நகரும் சாளரத்தில் அளக்கப்படுகிறது; பதிவேடு முழுவதற்குமான இரண்டாவது உச்சவரம்பு global_mint_cap_per_window எல்லா டோக்கன்களின் எல்லா ஆதாரங்களையும் சேர்த்து உள்ளடக்குகிறது (TokenError::GlobalMintCapExceeded). சங்கிலி 20-இல் அது 400,000,000,000 அலகுகள், 86,400 s-க்கு 4,000 zUSD. நாள் விதியின் கீழ், 23:59:59-இல் உச்சவரம்பும் மீண்டும் 00:00:01-இல் உச்சவரம்பும் என இரண்டு வினாடிகளில் உச்சவரம்பின் இருமடங்கு அனுமதிக்கப்பட்டது; சாளர விதியின் கீழ் இரண்டாவது மறுக்கப்படுகிறது.
• இடைநிறுத்தத்தின்போது பட்டியலிடல் இல்லை. mint_paused நிலையில் இருக்கும்போது RegisterBridgedToken-உம் ListBacking-உம் MintsPaused எனக் கூறி மறுக்கப்படுகின்றன. எரித்தல்களும் இரண்டு சுழற்சிகளும் திறந்தே உள்ளன.

சுழற்சி: உடைமை நிரூபணமும் ஒரு நாள் தாமதமும்

விதிகள் v2 மூன்று விஷயங்களைத் தீர்க்காமல் விட்டது: புதிய சாவிகள் யாரிடமாவது உள்ளன என்பதை எதுவும் நிரூபிக்கவில்லை (ஒரு எழுத்துப் பிழையோ, யாரிடமும் இல்லாத ஒரு சாவியோ குவாண்டம்-பிந்தைய குறைவெண்ணை நிரந்தரமாக முடக்கிவிடும்), ஒரு சுழற்சி அது சேர்ந்த தொகுதியிலேயே நடைமுறைக்கு வந்தது, பகைமையான சுழற்சியை எதுவும் தடுக்க முடியவில்லை. rules_v2-க்கு அருகில் உள்ள (அதைச் சார்ந்திருக்கும்) இரண்டாவது விருப்பத்தேர்வுக் குழு, v0.6.8-இல் புதியது (தணிக்கை v6, BRG-14), இவற்றைத் தீர்க்கிறது. சங்கிலி 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] என்பது குறைவெண் கையொப்பமிடும் அதே செய்தியின் மீது (M_rotate_pq அல்லது M_rotate_pause, சங்கிலி 20-இல் அவற்றின் …-2 வடிவில்) புதிய சாவி i-இன் சொந்த Dilithium2 கையொப்பம்; சாவி வரிசையில் ஒவ்வொரு சாவிக்கும் ஒன்று, ஒவ்வொன்றும் 2,420 பைட்டுகள். v1 செயல்கள் PossessionRequired எனக் கூறி மறுக்கப்படுகின்றன. தவறான எண்ணிக்கையோ நீளமோ குறைவெண் சரிபார்க்கப்படுவதற்கு முன்பே மறுக்கப்படுகிறது; தவறான உடைமைக் கையொப்பம் (BadPossession { index }) அதற்குப் பின் மறுக்கப்படுகிறது.
• ஒரு தாமதம். ஏற்கப்பட்ட சுழற்சி effective_at_secs = block time + delay_secs உடன் நிலுவையில் எனப் பதிவுசெய்யப்படுகிறது; நேரமுத்திரை அதை எட்டும் முதல் தொகுதியின் முடிவில் அது நடைமுறைக்கு வருகிறது. சங்கிலி 20-இல் அது 86,400 s, ஒரு நாள். அதுவரை பழைய தொகுப்பே ஒவ்வொரு அச்சிடலுக்கும் இணைக்கையொப்பமிடுகிறது, பழைய இடைநிறுத்தச் சாவியே இடைநிறுத்துகிறது. ஒரு சுழற்சியை ஏற்பது ஒரு rotation_nonce-ஐச் செலவிடுகிறது, அதைச் செயல்படுத்துவது இன்னொன்றைச் செலவிடுகிறது; எனவே பழைய தொகுப்பின் கீழ் தொகுப்புக்குளத்தில் சேர்க்கப்பட்ட அச்சிடல் சான்றுரை, தொகுப்பு மாறும்போது குளத்திலிருந்து வெளியேறுகிறது. ஒவ்வொரு வகையிலும் ஒரு நேரத்தில் ஒரு சுழற்சி மட்டுமே நிலுவையில் இருக்கலாம் (RotationPending { effective_at_secs }).
• ரத்து. CancelRotation { kind, nonce, signature } (தொகுப்பும் கட்டணமும் இல்லாதது) kind வகையின் நிலுவைச் சுழற்சியைக் கைவிடுகிறது (0 = குவாண்டம்-பிந்தைய தொகுப்பு, 1 = இடைநிறுத்தச் சாவி). இது குறைவெண்ணிலிருந்து தனியாக வைக்கப்பட்டுள்ள ஒரே சாவியான தற்போதைய இடைநிறுத்தச் சாவியால், சங்கிலி 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-ஐயும் வழங்குகிறது; இந்தக் குழு இல்லாத சங்கிலியில் (சங்கிலிகள் 14 முதல் 19) இரண்டும் null. ECDSA காவலர்-தொகுப்புச் சுழற்சி (payload 2) பாதிக்கப்படவில்லை: அது தன் சொந்த விதிகளையும் சலுகைக் காலத்தையும் வைத்திருக்கிறது. சங்கிலி 20-இல் இதுவரை எந்தச் சுழற்சியும் நடத்தப்படவில்லை.

சங்கிலி 14-இலிருந்து தொடர்வன

சங்கிலி 15 சங்கிலி 14-இன் பால நிலையிலிருந்து (அதே உமிழிகள், அதே மூல முனையங்கள்) பிரிக்கப்பட்டது; சங்கிலிகள் 16, 17, 18 ஒவ்வொன்றும் தன் முன்னோடியின் நிலையிலிருந்து அதே வழியில் பிரிக்கப்பட்டன. சங்கிலி 19 சங்கிலி 18-இன் நிலையிலிருந்து ஒரே ஒரு மாற்றத்துடன் பிரிக்கப்பட்டது: அதன் Ethereum, BSC, Tron உமிழிகள் 2026-09-30 அன்று மீண்டும் பயன்படுத்தப்பட்ட முனையங்கள் (சங்கிலிகள் 2, 3-க்கு 0x7af6b17047c1db6cb54347fdea45cf9179075bfa, சங்கிலி 4-க்கு 0x6410797df959987a5baf65b5fab97edeb34d5163). சங்கிலி 18 அவற்றை ஒருபோதும் நம்பவில்லை, எனவே அவற்றிலிருந்து அங்கு எதுவும் அச்சிடப்படவில்லை. சங்கிலி 20, பாலம் முதலில் நிறுத்தப்பட்ட பின், உயரம் 7,258-இல் எடுக்கப்பட்ட சங்கிலி 19-இன் நிலைப்படத்திலிருந்து பிரிக்கப்பட்டது; சங்கிலி 19-இன் உமிழிகள், காவலர்கள், குவாண்டம்-பிந்தைய சாவிகள், இடைநிறுத்தச் சாவி ஆகியவற்றை மாற்றமின்றி வைத்திருக்கிறது; அது சேர்ப்பவை கட்டணங்கள் மற்றும் சுழற்சி குழுக்கள். Solana-வின் உமிழியும் Rand-பக்க உமிழியும் சங்கிலி 14 முதல் மாறவில்லை. சங்கிலி 20-இன் தோற்றக் கோப்பு கொண்டிருப்பவை:

• காப்பு. 99 zUSD, இரண்டு ஜெனிசிஸ் zUSD குறிப்புகளாக (10 மற்றும் 89 zUSD), Ethereum-இல் பூட்டப்பட்ட 22 USDT, BSC-இல் 22 USDT, Tron-இல் 30 USDT மற்றும் Solana-வில் 25 USDT ஆகியவற்றுக்கு எதிராக உள்ளது; ஒவ்வொரு USDC ஆதாரத்திலும் 0. இது நிலைப்படம் எடுக்கப்பட்டபோது சங்கிலி 19-இன் locked மதிப்பு; அது முனையங்களின் காப்புடன் பொருந்தியது. தொகுதி 0-இல் total_supply == Σ locked முனையங்களின் காப்புக்குச் சமம். வரலாறு: சங்கிலி 14-இல் எஞ்சியிருந்த 10 zUSD, சங்கிலிகள் 15 முதல் 19 வரை ஒரே ஜெனிசிஸ் குறிப்பாக இருந்தது. சங்கிலி 18-இன் ஜெனிசிஸ் அவற்றை Tron-இல் பூட்டப்பட்ட 9 USDT மற்றும் Solana-வில் 1 என வைத்திருந்தது. சங்கிலி 18-இல் நடந்த மறுசமநிலைப்படுத்தலுக்குப் பின், சங்கிலி 19-இன் ஜெனிசிஸ் அவற்றை Solana-வில் 10 என வைத்திருந்தது. மற்ற 89, சங்கிலி 19-இன் நிகர வைப்புகளிலிருந்து அதன் எரிப்புகளைக் கழித்த தொகை.
• காப்பாளர் தொகுப்புக் குறியீடு 1: மூல முனையங்கள் ஏற்கெனவே இந்தக் குறியீட்டில் உள்ளன. அடுத்த ECDSA சுழற்சி குறியீடு 2-ஐக் கொண்டிருக்க வேண்டும். எட்டுப் பின்-குவாண்டம் சாவிகளும் இடைநிறுத்தச் சாவியும் சங்கிலி 15-இனுடையவை; அவை மாறவில்லை.
• burn_sequence 13: சங்கிலி 14-இன் எரிப்புகள் 6-இல் முடிந்தன; சங்கிலிகள் 15 முதல் 18 வரையிலான ஜெனிசிஸ் 7-இல் தொடங்கியது; சங்கிலி 18 ஒரு எரிப்பைச் (7) செய்தது; சங்கிலி 19, 8-இல் தொடங்கியது. சங்கிலி 19 ஐந்து எரிப்புகளைச் செய்தது (வரிசை எண்கள் 8 முதல் 12). ஆகவே சங்கிலி 20, 13-இல் தொடங்குகிறது. இதனால் வரிசை எண்ணைச் சாவியாகக் கொண்ட எந்த முனையமும் டீமனும் ஒரே எரிப்பை இருமுறை காண்பதில்லை. சங்கிலி 20-இன் முதல் எரிப்பு வரிசை எண் 13-ஐப் பெற்றது.
• மீள்செலுத்தல். முந்தைய சங்கிலியின் அச்சிடல் இன்னும் ECDSA கோரத்தைக் கடந்துவிடும். ஆனால் அதன் பின்-குவாண்டம் இணைக் கையொப்பம் அந்தச் சங்கிலியின் அடையாளத்துடன் பிணைக்கப்பட்டுள்ளது; ஆகவே சங்கிலி 20-இல் அது மறுக்கப்படுகிறது. சங்கிலி 15-இன் ஜெனிசிஸில் உள்வரும் மீள்செலுத்தல் வரம்பு இல்லை (min_inbound_sequence null ஆக இருந்தது). எனவே அங்கு இந்தப் பாதுகாப்பு இணைக் கையொப்பத்தையும், புதிய சங்கிலி அடையாளத்துக்காகப் பழைய பூட்டு எதற்கும் காப்பாளர்கள் ஒருபோதும் இணைக் கையொப்பமிடாததையும் சார்ந்திருந்தது. சங்கிலி 16 முதல் ஜெனிசிஸ் ஒரு வரம்பை அமைக்கிறது: ஒவ்வொரு மூலச் சங்கிலிக்கும், அந்தச் சங்கிலியின் வெளியீட்டாளரிடமிருந்து வரும் பரிமாற்றச் சான்றொப்பம் கொண்டிருக்கக்கூடிய மிகக் குறைந்த sequence. சங்கிலி 20-இன் வரம்பு { "2": 3, "3": 3, "4": 3, "5": 7 }. இவை சங்கிலி 19-இன் நிலைப்படம் எடுக்கப்பட்டபோது ஒவ்வொரு முனையத்தின் அடுத்த வெளிச்செல் வரிசை எண்கள்; அதற்கு முந்தைய ஒவ்வொரு பூட்டும் சங்கிலி 19-இல் அச்சிடப்பட்டுவிட்டது. (சங்கிலி 18-இனுடையது { "2": 2, "3": 2, "4": 2, "5": 2 }; சங்கிலி 19-இனுடையது { "2": 1, "3": 1, "4": 1, "5": 4 }. அதில் மீண்டும் வரிசைப்படுத்தப்பட்ட ஒவ்வொரு முனையத்திலும் வரிசை எண் 0 இயக்குநரின் சொந்தப் பூட்டு; அது ஒருபோதும் அச்சிடப்படக் கூடாது.) வரம்புக்குக் கீழுள்ள பரிமாற்றம், அது எந்தக் கோரத்தையும் இணைக் கையொப்பத்தையும் கொண்டிருந்தாலும், BelowReplayFloor என மறுக்கப்படுகிறது. காப்பாளர் தொகுப்புச் சுழற்சிகள் இந்த வரம்பால் மதிப்பிடப்படுவதில்லை. வரம்பு ஜெனிசிஸில் நிர்ணயிக்கப்படுகிறது; ஜெனிசிஸ் ஹாஷில் உறுதிசெய்யப்பட்டு, பால வேரில் உள்ளடக்கப்படுகிறது.

சங்கிலி 14-இல் தொடக்க வரிசை (வரலாறு)

முந்தைய testnet ஆன சங்கிலி 14-இல், செப்டம்பர் 2026-இல், பாலம் எவ்வாறு செயல்பாட்டுக்கு வந்தது:

1. bridge பிரிவுடன் (pq_guardians மற்றும் pause_key உட்பட), registration_fee மற்றும் mint_cap_per_day ஆகியவற்றை அமைக்கும், எந்த டோக்கனையும் பட்டியலிடாத tokens பிரிவுடன் சங்கிலியை உருவாக்குதல். 2026-09-20 அன்று முடிந்தது.
2. வரிசைப்படுத்தும் வாலட் RAND பெறுவதற்காக ஃபாசெட்டை இயக்குதல். முடிந்தது.
3. list_nonce = 0-இல் M_register மீதான கோரத்தின் கையொப்பத்தின் கீழ், வரிசைப்படுத்துபவர் zUSD-ஐ அதன் முதல் ஆதாரத்துடன் பதிவுசெய்கிறார். உயரம் 256-இல் முடிந்தது.
4. காப்பாளர்கள் குறியீட்டைத் திரும்பப் படித்து, மீதமுள்ள ஆறு ListBacking செய்திகளில் கையொப்பமிடுகின்றனர்; அவை ஒவ்வொன்றாகச் சமர்ப்பிக்கப்படுகின்றன. முடிந்தது: list_nonce 7 எனக் காட்டுகிறது.
5. ஒவ்வொரு ஆதாரத்துக்கும்: மூல முனையத்தில் setToken செய்வதற்கு முன் Rand-இல் பட்டியலிடுதல்.
6. நான்கு மூல முனையங்களிலும் காப்பாளர் தொகுப்புச் சுழற்சி (தொகுப்பு 0 → தொகுப்பு 1, நடப்புத் தொகுப்பால் 6-இல் 5 கையொப்பங்களுடன்), பின்னர் அதே சான்றொப்பம் Rand-இல். சங்கிலி 14-இன் வாழ்நாள் முழுவதும் Rand தொகுப்பு 0-ஐக் காட்டியது; சங்கிலி 15 தொகுப்பு 1-இல் தொடங்குகிறது.
7. ஒவ்வொரு மூலச் சங்கிலிக்கும் சிறு தொகைகளுடன் ஒரு நேரடிச் சுற்றுப் பயணம் (பாலத்தின் வழியே உள்ளே, 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 பொதுச் சாவிகள்; ஒவ்வொன்றும் hex வடிவில் 1,312 பைட்டுகள். next_index இனி இல்லை: பாலம் வழியே வரும் டோக்கன், வைப்புச் செய்யப்படுவதற்கு முன்பே, அதன் பதிவு நிர்ணயித்த குறியீட்டின் கீழ் பட்டியலிடப்படுகிறது; ஆகவே முன்கணிக்க வேண்டிய குறியீடு எதுவும் இல்லை. அடுத்த M_rotate_pq/M_rotate_pause/M_cancel கொண்டிருக்க வேண்டியது rotation_nonce. அந்தக் குழு இல்லாத சங்கிலியில் (சங்கிலி 14) rules_v2 null ஆகும். மீள்செலுத்தல் வரம்பு இல்லாத சங்கிலியில் (சங்கிலி 15 மற்றும் அதற்கு முந்தையவை) min_inbound_sequence null ஆகும்; சங்கிலி 20-இல் அது { "2": 3, "3": 3, "4": 3, "5": 7 }. அந்தக் குழுக்கள் இல்லாத சங்கிலியில் (சங்கிலிகள் 14 முதல் 19) rotation_rules, pending_rotations மற்றும் fees null ஆகும். மேலே உள்ள மாதிரி வடிவத்தைக் காட்டுகிறது, சங்கிலி 20-இன் மதிப்புகளை அல்ல: சங்கிலி 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…" } ஆகியவற்றை வழங்குகிறது. bridge பிரிவு இல்லாத சங்கிலி {"enabled": false} எனப் பதிலளிக்கிறது.

இருப்புகள் இல்லை: பாலம் வழியே வந்த மதிப்பு குறிப்புகளாக உள்ளது; ஒரு வாலட் தான் வைத்திருப்பதைத் தன் சொந்தக் குறிப்புகளிலிருந்து rand asset-balance [INDEX] மூலம் படிக்கிறது. பால வேர் பின்வருவனவற்றை உறுதிசெய்கிறது: வெளியீட்டாளர்கள், காப்பாளர் தொகுப்புகள், செலவிடப்பட்ட சுருக்கங்கள், எரிப்பு வரிசை எண், பின்-குவாண்டம் காப்பாளர் தொகுப்பு, இடைநிறுத்தச் சாவி, இடைநிறுத்தக் கொடி, ஆளுகை nonce-கள் (இரண்டு, rules v2-இன் கீழ் rotation_nonce), ஜெனிசிஸ் அமைக்கும் இடங்களில் மீள்செலுத்தல் வரம்பு, மேலும் சங்கிலி 20-இல் நிலுவையிலுள்ள சுழற்சிகளுடன் சுழற்சி விதிகள் மற்றும் கட்டணக் குழு. பாலம் உள்ள சங்கிலியில் மட்டுமே அது நிலை வேரில் சேர்க்கப்படுகிறது. ஒவ்வொரு ஆதாரத்தின் locked உடன் கூடிய டோக்கன் பதிவேடு, tokens_root ஆகத் தனியாக உறுதிசெய்யப்படுகிறது. எக்ஸ்ப்ளோரரின் GET /bridge மற்றும் GET /bridge/assets அதே நிலையை வழங்குகின்றன; இரண்டாவது, ஒவ்வொரு ஆதாரத்துக்குமான வைப்பு மற்றும் எரிப்பு மொத்தங்களை 8-தசம இலக்கச் சரங்களாகத் தருகிறது. GET /tokens மற்றும் GET /tokens/:id பதிவேட்டை வழங்குகின்றன.

எது பொதுவானது, எது மறைக்கப்பட்டது

அறியப்பட்ட குறைபாடுகள்

முழுக்கணுவின் சொந்தப் பட்டியலிலிருந்து: Rand-இல் எந்த இடைமாற்றிக்கும் கட்டணம் வழங்கப்படுவதில்லை. ஒரு வைப்பின் உறை எதனுடனும் பிணைக்கப்படவில்லை; ஆகவே பகைமையான இடைமாற்றி குப்பைத் தரவை முத்திரையிட முடியும். அதனால்தான் வாலட் வைப்புக் குறிப்புகளைப் பொதுப் புலங்களிலிருந்து மீளுருவாக்குகிறது. லெட்ஜர் மட்டத்தில் பகிரப்பட்ட சோதனை வெக்டர்கள் குறிப்புக் குளத்தின் மீது இன்னும் மீளுருவாக்கப்படவில்லை. சேருமிட முனையத்தின் சொந்தக் கொள்கையைப் பற்றி bridge-burn இன்னும் ஒரு நிரூபணத்துக்குக் கட்டணம் செலுத்திய பிறகே அறிகிறது. பாலம் உள்ள சங்கிலியில், பெற்றோர் தொகுதியின் நேர முத்திரைக்குச் சமமான தொகுதி நேர முத்திரைகள் அனுமதிக்கப்படுகின்றன; ஆகவே கூட்டுச்சேரும் தலைவர்கள், மாற்றீடு செய்யப்பட்ட காப்பாளர் தொகுப்பை அதன் சலுகைக் காலத்துக்குள் தக்கவைக்க முடியும். நினைவகத்திலுள்ள எரிப்புப் பதிவுக்கு வரம்பு இல்லை. மூலச் சங்கிலி நிலைக்கான இலகு கிளையண்டோ சங்கிலியிலேயே செய்யப்படும் சரிபார்ப்போ இல்லை; அவை திட்டமிடப்படவும் இல்லை.