இந்தப் பக்கம் Rand-இன் ஒவ்வொரு முக்கிய வடிவமைப்பு முடிவுக்கான காரணத்தைப் பதிவு செய்கிறது. ஒரு கூறு வழங்க வேண்டிய பண்பு, அதை வழங்குவதற்கான அனுமானம், அதற்கு ஈடாக ஏற்றுக்கொள்ளப்பட்ட செலவு ஆகியவை இதில் அடங்கும். இது 29 September 2026 அன்று இந்தத் தளம், வெள்ளையறைச் சுருக்கம், மேற்கோள் முழு நோடு (github.com/randprotocol/fullnode: அதன் README, docs/ மற்றும் docs/superpowers/specs/) ஆகியவற்றிலிருந்து தொகுக்கப்பட்டது. ஒவ்வொரு பதிலும் அந்தக் காரணம் கூறப்பட்டுள்ள ஆவணத்தைச் சுட்டுகிறது; randprotocol.org என்று தொடங்காத பாதைகள் fullnode களஞ்சியத்தைக் குறிக்கும்.
நிலை. Rand நிறுவனர் குழுவால் இயக்கப்படும் testnet-இல் இயங்குகிறது; நெறிமுறை சுயாதீனமாகத் தணிக்கை செய்யப்படவில்லை. கீழுள்ள சில முடிவுகள் சங்கிலி வெட்டுகள் (chain cuts) வழியாகப் படிப்படியாகச் செயல்படுத்தப்படுகின்றன. அனைத்து எண்ணிக்கைகளும் தொகுத்த நேரத்தில் இயங்கிய நோடின் அளவீடுகள்; அவை மாறக்கூடும், மேற்கோள் காட்டும் முன் மீண்டும் அளக்கப்பட வேண்டும்.
குறியாக்கவியல் அடிப்படைக் கூறுகள்
1. குறிப்பு (note) குறியாக்கத்துக்கு ML-KEM-768 (Kyber) ஏன்?
ஒரு குறிப்பின் மூல உரை, பொதுப் பேரேட்டில் காலவரையின்றி இருக்கும் ஓர் உறையில் (envelope) அதைப் பெறுபவருக்காகக் குறியாக்கம் செய்யப்படுகிறது. எனவே அதன் ரகசியத்தன்மை திரும்பப்பெற இயலாத பண்பாகும் (கேள்வி 8): பிற்காலத்தில் எப்போதேனும் குறியாக்கவியலுக்குப் பொருத்தமான குவாண்டம் கணினியைப் பெறும் எதிரி, நீள்வட்ட வளைவு KEM-இன் கீழ் மூடப்பட்ட அனைத்து வரலாற்று உறைகளையும் மறைகுறி நீக்க முடியும்; ஏனெனில் Shor-இன் வழிமுறை தனிநிலை மடக்கையைப் (discrete logarithm) பல்லுறுப்புக்கோவை நேரத்தில் தீர்க்கிறது. ML-KEM NIST FIPS 203-இல் தரப்படுத்தப்பட்டுள்ளது; அதன் பாதுகாப்பு Module-LWE-க்குச் சுருங்குகிறது, இதற்குத் திறன்மிக்க குவாண்டம் வழிமுறை எதுவும் அறியப்படவில்லை. ஒவ்வொரு முகவரியும் சுமக்க வேண்டிய 1,184-பைட் உறையிடல் விசைக்கும் (encapsulation key) பாதுகாப்பு விளிம்புக்கும் இடையிலான சமரசமாக 768 அளவுருத் தொகுப்பு (NIST பிரிவு 3) தேர்ந்தெடுக்கப்பட்டது. உறை என்பது ML-KEM-768 உடன் ChaCha20-Poly1305 இணைந்தது: 1,348 பைட், நிலையான memo புலத்துடன் 1,860 பைட்.
மூலம்: randprotocol.org (குவாண்டத்துக்குப் பிந்தைய பிரிவு); fullnode README; docs/shielded.md §2
2. Pedersen-க்குப் பதிலாக Poseidon2 உறுதிப்பாடுகள் (commitments) ஏன்?
Pedersen உறுதிப்பாடுகள் முழுமையாக மறைப்பவை (perfectly hiding); ஆனால் கணக்கீட்டு அடிப்படையில் மட்டுமே பிணைப்பவை (computationally binding). அவற்றின் பிணைப்பு தனிநிலை மடக்கை அனுமானத்துக்குச் சுருங்குகிறது; குவாண்டம் எதிரி அதை முறிக்கிறான். தனிநிலை மடக்கைகளைக் கணக்கிடக்கூடிய எதிரி, ஓர் உறுதிப்பாட்டை வேறொரு மதிப்புக்குத் திறக்க முடியும். இன்று வெளியிடப்படும் உறுதிப்பாடு பேரேட்டின் ஆயுள் முழுவதும் சரியானதாகவும் மறைப்பதாகவும் இருக்க வேண்டும் என்பதால், குவாண்டம் எதிரிகளுக்கு எதிராக நிலைக்கும் என நம்பப்படும் அனுமானங்களின் மேல் திட்டம் அமைய வேண்டும்; நடைமுறையில் இது ஒரு ஹாஷ் சார்பைக் குறிக்கும். Poseidon2 என்பது Goldilocks புலத்தின் மேல் வரையறுக்கப்பட்ட, எண்கணிதமாக்கலுக்கு (arithmetisation) ஏற்ப வடிவமைக்கப்பட்ட ஹாஷ்; எனவே STARK-க்குள் அதை மதிப்பிடுவதற்குக் குறைவான கட்டுப்பாடுகளே தேவை. குறிப்பு உறுதிப்பாடு, ஆழம்-32 Merkle மரம், நல்லிஃபயர் (nullifier) ஆகிய மூன்றையும் இதே ஹாஷ் செயல்படுத்துகிறது.
மூலம்: randprotocol.org (குவாண்டத்துக்குப் பிந்தைய பிரிவு); docs/shielded.md §1–2
3. BLAKE3, Poseidon2 என இரண்டு ஹாஷ் சார்புகள் ஏன்?
இரண்டு சார்புகளும் வெவ்வேறு செலவு மாதிரிகளுக்கு உகந்தவை. ஒரு நிரூபணத்துக்குள் ஹாஷ் மதிப்பிடப்பட வேண்டிய இடங்களில் — குறிப்புகள், உறுதிப்பாட்டு மரம், நல்லிஃபயர்கள், zkVM-இன் உள் அட்டவணைகள் — Poseidon2 பயன்படுத்தப்படுகிறது; ஏனெனில் அதன் செலவு கட்டுப்பாடுகளில் அளக்கப்படுகிறது. நிரூபணம் எதுவும் தொடர்புடையதாக இல்லாத, இயல்பான (native) செயல்திறன் முதன்மையாக உள்ள இடங்களில் BLAKE3 பயன்படுத்தப்படுகிறது: தொகுதி ஹாஷ்கள்; மரம், நல்லிஃபயர் தொகுப்பு, வேலிடேட்டர் பதிவேடு, நிரல் அட்டவணை ஆகியவற்றின் மேலான நிலை வேர் (state root); வேலிடேட்டர் முகவரிகள் (பொது விசையின் BLAKE3 digest). Poseidon2 CPU-வில் ஒப்பீட்டளவில் மெதுவானது; BLAKE3 எண்கணிதமாக்க ஒப்பீட்டளவில் செலவு மிக்கது. ஒவ்வொன்றும் அதன் செலவு மாதிரி பொருந்தும் இடத்தில் மட்டுமே பயன்படுத்தப்படுகிறது.
மூலம்: fullnode README (signatures / hashes வரிசை); docs/architecture.md
4. வேலிடேட்டர் கையொப்பங்களுக்கு Dilithium2 (ML-DSA) ஏன்?
ஒருமித்த கருத்து (consensus) கையொப்பங்கள் புதுப்பிக்கத்தக்க பண்பை வழங்குகின்றன (கேள்வி 8): திட்டம் பிற்காலத்தில் முறிந்தால் எதிர்கால செய்திகளைப் போலியாக உருவாக்க முடியும்; ஆனால் ஏற்கனவே இறுதிசெய்யப்பட்ட தொகுதிகள் பின்னோக்கிச் செல்லுபடியற்றவை ஆகாது. எனவே குவாண்டம் எதிரி தோன்றும் முன் திட்டத்தை மாற்ற முடியும். இருப்பினும், ஒருமித்த கருத்து வாக்குகள், பாலக் காவலர்களின் (bridge guardians) இணைக் கையொப்பங்கள், வேலிடேட்டர் பதிவேடு ஆகியவை ஒரே குவாண்டத்துக்குப் பிந்தைய விசை வகையைப் பகிர வேண்டும் என்பதற்காக, தொடக்க நிலையிலிருந்தே லாட்டிஸ் அடிப்படையிலான திட்டம் ஏற்கப்பட்டது. நோடு இறுதி FIPS 204 ML-DSA-44-இலிருந்து வேறுபட்ட round-3 Dilithium2 அளவுருத் தொகுப்பைச் (crystals-dilithium crate) செயல்படுத்துகிறது; பொது விசைகள் 1,312 பைட், கையொப்பங்கள் 2,420 பைட்.
மூலம்: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. SNARK-க்குப் பதிலாக ஒளிவுமறைவற்ற STARK (Goldilocks மேல் FRI) ஏன்?
இந்தத் தேர்வு மூன்று தேவைகளிலிருந்து பெறப்படுகிறது. முதலாவது, நம்பகமான அமைப்பு (trusted setup) இல்லாமை: நம்பகத்தன்மை ஒரு ஹாஷ் சார்பின் மோதல் எதிர்ப்பின் மீது மட்டுமே சார்ந்துள்ளது; கட்டமைக்கப்பட்ட மேற்கோள் சரம் (structured reference string) அல்லது pairing-க்கு உகந்த வளைவின் மீது அல்ல. இரண்டாவது, நம்பத்தக்க குவாண்டத்துக்குப் பிந்தைய உறுதித்தன்மை: இந்த வாதம் தனிநிலை மடக்கை அல்லது pairing அனுமானம் எதையும் செய்யவில்லை. மூன்றாவது, கேள்வி 2-இல் உள்ள ஹாஷ் அடிப்படையிலான உறுதிப்பாட்டுத் திட்டத்துடன் இணக்கம். இதற்கான செலவு நிரூபண அளவு: ஒரு bundle நிரூபணம் ஏறத்தாழ 1.3 MB, அதாவது Zcash அல்லது Monero shielded பரிவர்த்தனையின் அளவைவிட 300–600 மடங்கு. இந்தச் செலவு ஏற்கப்பட்டது; அது தொகுதி மட்ட ஒருங்கிணைப்பால் (block-level aggregation) தனியாகக் கையாளப்படுகிறது (கேள்விகள் 31, 34).
மூலம்: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. 27-க்குப் பதிலாக 80-query FRI சுயவிவரம் ஏன்?
உற்பத்தி சுயவிவரம் (80 queries, blowup காரணி 8, 20 பிட் proof-of-work grinding) ஏறத்தாழ 86 பிட் நிரூபிக்கத்தக்க உறுதித்தன்மையை வழங்குகிறது; 27-query சுயவிவரம் ஏறத்தாழ 42 பிட் வழங்குகிறது; நிரூபண அளவு 2.75 மடங்கு. சரிபார்ப்பு நேரம் கிட்டத்தட்ட மாறவில்லை: cold நிலையில் 809 ms இலிருந்து 838 ms ஆக உயர்கிறது, warm நிலையில் ஏறத்தாழ 16 ms. நிரூபிக்கத்தக்க உறுதித்தன்மைக்கு நிரூபண அளவைவிட முன்னுரிமை வழங்கப்பட்டது; அளவுச் செலவு தொகுதி இடம் மற்றும் ஒருங்கிணைப்பு வடிவமைப்புக்கு மாற்றப்பட்டது.
மூலம்: docs/block-space.md §1, §3
7. குவாண்டத்துக்குப் பிந்தைய கூற்று ‘நெறிமுறை முழுவதும் 128-பிட்’ என்று அல்லாமல் ஒவ்வொரு அடிப்படைக் கூறுக்கும் ஏன் தனித்தனியாகக் கூறப்படுகிறது?
முந்தைய வரைவுகள் நெறிமுறை முழுமைக்கும் 128-பிட் குவாண்டத்துக்குப் பிந்தைய பாதுகாப்பைக் கூறின. அந்தக் கூற்று Brassard–Høyer–Tapp வரம்புடன் முரண்படுகிறது; அதன்படி குவாண்டம் எதிரி 256-பிட் ஹாஷில் மோதல்களை ஏறத்தாழ 2^85 queries-இல் கண்டுபிடிக்கிறான். எனவே அது நிபந்தனைகளுடன் தக்கவைக்கப்படாமல் திரும்பப் பெறப்பட்டது. இப்போது ஆய்வறிக்கை பாதுகாப்பை ஒவ்வொரு அடிப்படைக் கூறுக்கும் ஒவ்வொரு பங்குக்கும் தனித்தனியாகக் கூறுகிறது — 384-பிட் transcript ஹாஷ், முன்படம் எதிர்ப்பு (preimage resistance) மட்டும் தேவைப்படும் இடங்களில் மட்டும் பயன்படுத்தப்படும் 256-பிட் ஹாஷ்கள், Dilithium2, ML-KEM-768, விரிவாக்கப் புலத்தின் மேல் FRI — இவை அனைத்தும் Module-LWE மற்றும் Module-SIS அனுமானங்களின் கீழ், ஹாஷ் சார்புகள் குவாண்டம் சீரற்ற ஆரக்கிள்களாக (quantum random oracles) மாதிரியாக்கப்பட்டவை. நோடின் transcript ஹாஷ் தற்போது Poseidon2; ஆவணங்கள் இதைத் திறந்த உள்ளமைவு இடைவெளியாகப் பட்டியலிடுகின்றன.
மூலம்: randprotocol.org (குவாண்டத்துக்குப் பிந்தைய பிரிவு)
8. ‘திரும்பப்பெற இயலாதது எதிர் புதுப்பிக்கத்தக்கது’ என்ற வகைப்பாடு என்ன, அது தேர்வுகளை ஏன் இயக்குகிறது?
எதிர்காலத்தில் எப்போது வேண்டுமானாலும் புதிய திறனைப் பெறும் எதிரி, ஏற்கனவே வெளியிடப்பட்ட தரவுக்கு அந்தப் பண்பை பின்னோக்கி மீற முடியுமெனில் அது திரும்பப்பெற இயலாதது; குறிப்பு ரகசியத்தன்மையும் உறுதிப்பாட்டு மறைப்பும் இவ்வகையைச் சேர்ந்தவை, எனவே அவை வெளியிடப்படும் நேரத்திலேயே குவாண்டம் எதிர்ப்புடன் இருக்க வேண்டும். ஒவ்வொரு பயன்பாட்டிலும் அந்தப் பண்பு மீண்டும் நிறுவப்படுமெனில் அது புதுப்பிக்கத்தக்கது; அச்சுறுத்தல் தோன்றும் முன் திட்டத்தை மாற்ற முடியும்; கையொப்பங்களும் நிரூபண உறுதித்தன்மையும் இவ்வகையைச் சேர்ந்தவை. இந்தப் பிரிவில் உள்ள ஒவ்வொரு அடிப்படைக் கூறின் தேர்வும், அது பாதுகாக்கும் பண்பை வகைப்படுத்துவதிலிருந்தே பெறப்படுகிறது.
மூலம்: randprotocol.org (குவாண்டத்துக்குப் பிந்தைய பிரிவு)
shielded தொகுப்பு (pool)
9. கணக்குகளோ இருப்புகளோ இல்லாமல் குறிப்பு/UTXO மாதிரி ஏன்?
கணக்கு அடிப்படையிலான பேரேடு இயல்பாகவே இருப்புகளை வெளியிடுகிறது; அவற்றை மறைக்க நிலையை குறியாக்கம் செய்து, மறைகுறியிடப்பட்ட உரைகளின் மேல் கூற்றுகளை நிரூபிக்க வேண்டும், இது கணிசமாகச் செலவு மிக்கது. குறிப்புத் தொகுப்பு உறுதிப்பாடுகளையும் நல்லிஃபயர்களையும் மட்டுமே சேமிக்கிறது; இரண்டும் உரிமையாளரையோ தொகையையோ வெளிப்படுத்துவதில்லை, எனவே பொது நிலையில் இருப்புத் தகவல் எதுவும் இல்லை. ஒரே விதிவிலக்கு வேலிடேட்டர் பதிவேடு: அதன் stake எடைகள் பொதுவில் இருக்க வேண்டும், அப்போதுதான் பிரதிகள் (replicas) quorum உறுப்பினர் குறித்து உடன்பட முடியும் (கேள்வி 29).
மூலம்: docs/shielded.md §1–2; docs/staking.md §1
10. முகவரி ஏறத்தாழ 1.6 KB ஏன்?
shielded முகவரி 32-பைட் உரிமையாளர் புலமான pk மற்றும், உறையை மூட அனுப்புநருக்குத் தேவைப்படும் 1,184-பைட் ML-KEM-768 உறையிடல் விசை ஆகியவற்றைக் கொண்டுள்ளது; base58 குறியீட்டில் இது ஏறத்தாழ 1,667 எழுத்துகள். இந்த நீளம் குவாண்டத்துக்குப் பிந்தைய KEM-இன் நேரடி விளைவு. அங்கீகரிக்கப்பட்ட ஒரு வடிவமைப்பு (short shielded addresses, 2026-09-17) முகவரியை ஏறத்தாழ 256 பிட் அளவிலான பெறுநர் அடையாளங்காட்டியால் (receiver identifier) மாற்றுகிறது; அது spend விசையால் கையொப்பமிடப்பட்டு explorer-ஆல் வழங்கப்படும், புதுப்பிக்கத்தக்க பதிவுக்குத் தீர்வாகிறது. இதனால் உறையிடல் விசையைப் படியெடுக்காமல் பெற முடிகிறது.
மூலம்: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. ஒவ்வொரு விசையும் ஒரே 256-பிட் spend விசையிலிருந்து ஏன் பெறப்படுகிறது?
மற்ற அனைத்து விசைப் பொருட்களும் ஒரே ரகசியமான sk-இன் தீர்மானமான சார்புகள்: viewing key nk = H(NK, sk), உரிமையாளர் புலம் pk = H(PK, nk), நல்லிஃபயர் H(NF, nk, cm), வெளிச்செல்லும் viewing key, ML-KEM மறைகுறி நீக்க விசை — ஒவ்வொன்றும் தனக்கே உரிய domain பிரிப்பானின் கீழ். எனவே விசைக் கோப்பு sk-ஐ மட்டுமே சேமிக்கிறது, காப்புப்பிரதி ஒரே மதிப்பு, மரத்தை இலை 0-இலிருந்து மீண்டும் ஸ்கேன் செய்தால் ஒவ்வொரு குறிப்பும் மீட்கப்படும். மீட்டெடுக்க இரண்டாவது நகல் இல்லாததால், இருக்கும் விசைக் கோப்பை மேலெழுத wallet மறுக்கிறது.
மூலம்: docs/shielded.md §1
12. நிலையான 4-in-4-out bundle வடிவம் ஏன்?
நிலையான வடிவம், எதை நகர்த்தினாலும் ஒவ்வொரு bundle-ஐயும் ஒரே அளவிலும் அமைப்பிலும் ஆக்குகிறது. ஒவ்வொரு bundle-உம் சரியாக நான்கு நல்லிஃபயர்களையும் நான்கு உறுதிப்பாடுகளையும் வெளியிடுகிறது; பயன்படுத்தப்படாத இடங்கள் பூஜ்ய மதிப்புள்ள dummy குறிப்புகள்; change வெளியீட்டின் மதிப்பு பூஜ்யமாக இருந்தாலும் அது வெளியிடப்படுகிறது, ஏனெனில் change வெளியீடு இல்லாதிருந்தால் அது பரிவர்த்தனையை வேறுபடுத்திக் காட்டும். அசல் விவரக்குறிப்பு Sapling-ஐப் பின்பற்றி 2-in-2-out ஆக இருந்தது. மறைக்கப்பட்ட சொத்து bundle-உடன் இது 4-in-4-out ஆக விரிவாக்கப்பட்டது; இதனால் இடங்கள் 0–1 தனியார் சொத்தையும் இடங்கள் 2–3 கட்டணத்துக்கான RAND-ஐயும் சுமக்கின்றன; மூன்றுக்குப் பதிலாக நான்கு இடங்கள் இருப்பதால், ஒரு token பரிமாற்றம் அதன் கட்டணத்தை இரண்டு RAND குறிப்புகள் வரை கொண்டு செலுத்த முடிகிறது.
மூலம்: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. ஒரே நிரூபணம் எந்தச் சொத்தையும் (RAND, zUSD, RPL tokens) ஏன் நகர்த்த முடிகிறது?
Before chain 14, a token transfer carried two bundles, one for the RAND fee and one for the asset, which required two proofs and revealed to any observer which token had moved. (This opening paragraph is the only part I haven’t rendered below, because the translation starts after it.)
Chain 14-க்கு முன்பு, ஒரு டோக்கன் பரிமாற்றம் இரண்டு பண்டில்களைக் கொண்டிருந்தது: ஒன்று RAND கட்டணத்துக்கு, மற்றொன்று சொத்துக்கு. இதற்கு இரண்டு நிரூபணங்கள் தேவைப்பட்டன; எந்த டோக்கன் நகர்ந்தது என்பதையும் எந்தவொரு பார்வையாளருக்கும் அது வெளிப்படுத்தியது. மறைக்கப்பட்ட-சொத்து guest சொத்து அடையாளங்காட்டியை தனிப்பட்ட உள்ளீடாக எடுத்துக்கொள்வதால், zUSD பரிமாற்றத்தை RAND செலுத்துதலிலிருந்து பிரித்தறிய முடியாது. இந்த guest, tier 14-இல் (ஏறத்தாழ 100 s மற்றும் 5.7 GB நினைவகம்) பொருந்துவதற்குக் காரணம், அது தன் உள்ளீடுகளை ஒரு சுழற்சியில் படித்து, Merkle உறுப்பினர் சரிபார்ப்பை இணைத்துச் செயல்படுத்துவதே ஆகும்; முழுமையாக விரிக்கப்பட்ட செயலாக்கத்துக்கு tier 16 (ஏறத்தாழ 400 s மற்றும் 21 GB) தேவை; அது 16 GB இயந்திரத்தின் நினைவகத்தைவிட அதிகம்.
ஆதாரம்: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. கட்டணம் ஏன் பொதுவெளியில் இருக்கிறது, அது ஏன் முன்மொழிபவருக்குச் செலுத்தப்படுகிறது?
பொதுக் கட்டணம் பொது stake பதிவேட்டுடன் இசைவானது; மேலும் அனுமதியைச் செலவு குறைந்ததாக்குகிறது: எந்தச் சரிபார்ப்பையும் செய்வதற்கு முன்பே ஒரு நோடு கட்டணத் தளத்தைச் சரிபார்க்க முடியும். பண்டில் நிரூபணம் Σ inputs = Σ outputs + fee + burn என்ற சமநிலைச் சமன்பாட்டை நடைமுறைப்படுத்துகிறது; எனவே கட்டணம் எந்த நோட்டுகள் என்பதை வெளிப்படுத்தாமல், மறைக்கப்பட்ட நோட்டுகளிலிருந்து செலுத்தப்படுகிறது. ஏற்றுக்கொள்ளப்பட்ட விலை என்னவென்றால், கட்டணத் தொகை பரிவர்த்தனையின் வகையை (பரிமாற்றம் அல்லது நிரல் அழைப்பு) வெளிப்படுத்தக்கூடும்.
ஆதாரம்: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (தீர்ப்புகள் அட்டவணை); docs/fees.md §1
15. வைப்புகளுக்கு (mint, bridge attest) ஏன் பொதுத் தொகை உள்ளது?
குளத்துக்குள் நுழையும் மதிப்பு பொதுவெளியில் கணக்கிடப்பட வேண்டும்; bridge அத்தாட்சி என்பது மூலச் சங்கிலியில் அதற்கு இணையான பூட்டல் நடந்தது என்பதற்கான பொதுச் சான்று. இதனால் ஏற்படும் புலப்பாடு நுழைவுப் படிக்கு மட்டுமே வரையறுக்கப்பட்டது; இது Zcash-இல் வெளிப்படையிலிருந்து-கவசமிட்டதற்கான (t-to-z) பரிவர்த்தனைக்கு ஒப்பானது; வைக்கப்பட்ட நோட்டின் பின்னர் வரும் செலவுகள் மறைக்கப்படுகின்றன.
ஆதாரம்: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (பொதுவில் உள்ளவை அட்டவணை)
16. மெமோ ஏன் நிலையான 512-பைட் புலமாக உள்ளது?
நிலையான நீளமுள்ள புலம், மெமோ இருக்கிறதா அல்லது அது எவ்வளவு நீளம் என்பதை லெட்ஜர் வெளிப்படுத்தாமல் இருப்பதை உறுதிசெய்கிறது: மெமோ இயக்கப்பட்ட சங்கிலியில், போலிகள் மற்றும் மீதிகள் உட்பட நோட்டை உருவாக்கும் ஒவ்வொரு உறையும் சரியாக 1,860 பைட்டுகள் ஆகும். மெமோ குறியாக்கப்பட்ட உறைக்குள் மட்டுமே கொண்டுசெல்லப்படுகிறது; நோட்டிலோ, உறுதிப்பாட்டிலோ (commitment), நிரூபணத்திலோ ஒருபோதும் இல்லை; ஏற்கெனவே அந்த நோட்டை மறைகுறி நீக்க முடிந்த தரப்பினரால் மட்டுமே படிக்கப்படுகிறது. சிதைந்த மெமோ வெற்று மெமோவாகவே குறிநீக்கப்படுகிறது; இதனால் அது நோட்டையே மீட்க முடியாததாக ஆக்க முடியாது.
ஆதாரம்: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. நிரூபணம் ஏன் உள்ளூரில் நடக்கிறது, பிரதிநிதித்துவ நிரூபிப்பான் அதை எப்படிக் குலைக்காமல் இருக்கிறது?
நிரூபணமே செலவு அங்கீகாரம்: பண்டிலில் கையொப்பமோ அனுப்புநர் புலமோ இல்லை; எனவே செலவு விசை வாலட்டை விட்டு வெளியேற வேண்டியதே இல்லை. tier-14 பண்டில் நிரூபணத்துக்கு ஏறத்தாழ 5.7 GB நினைவகம் தேவை; இது தொலைபேசிகளும் உலாவிகளும் வழங்கக்கூடியதைவிட அதிகம்; அதனால்தான் பிரதிநிதித்துவ நிரூபிப்பான். பிரிக்கப்பட்ட அங்கீகாரம் (bundle guest v3, genesis அளவுரு hc_auth) இரு பங்குகளையும் பிரிக்கிறது: நிரூபிப்பான் பார்வை விசை nk-ஐ மட்டுமே பெற்று பண்டில் நிரூபணத்தை உருவாக்குகிறது; வாலட் sk-ஐப் பயன்படுத்தி சிறிய tier-10 அங்கீகார நிரூபணத்தை உருவாக்குகிறது. எனவே நிரூபிப்பானால் பண்டில் நிரூபணத்தை உருவாக்க முடியும், ஆனால் செலவை அங்கீகரிக்க முடியாது (கேள்வி 36).
ஆதாரம்: docs/prover.md §1; docs/shielded.md (பிரிக்கப்பட்ட அங்கீகாரம்); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. நங்கூர சாளரம் ஏன் 256 தொகுதிகள்?
நிரூபணம் ஒரு குறிப்பிட்ட commitment-மரத்தின் வேருக்கு (அதன் நங்கூரம்) எதிராக உருவாக்கப்படுகிறது; tier-14 பண்டில் நிரூபணத்தை உருவாக்க ஏறத்தாழ 100 s ஆகிறது. எனவே சமர்ப்பிக்கும் நேரத்தில் பல நிமிடங்கள் பழைமையான நங்கூரங்களை லெட்ஜர் ஏற்க வேண்டும். அசல் விவரக்குறிப்பில் சாளரம் 64 தொகுதிகளாக இருந்தது; தொகுதி இடைவெளி குறைந்ததால் அது 256 தொகுதிகளாக விரிவாக்கப்பட்டது; இதனால் அதன் சுவர்-கடிகார கால அளவு நிரூபண நேரத்துக்கு மேலாகவே இருக்கிறது.
ஆதாரம்: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM மற்றும் இரகசியக் கணிப்பு
19. guest ISA-வாக RV32I ஏன் (RV64 ஏன் அல்ல)?
32-பிட் சொல் சரியாக நான்கு பைட் உறுப்புகளாகப் பிரிகிறது; Goldilocks பகாவெண் p = 2^64 − 2^32 + 1 இரண்டு 32-பிட் மதிப்புகளின் பெருக்கல் புலத்தைத் தாண்டி வழியாத அளவுக்குப் பெரியது. RV64, ALU மற்றும் நினைவக அட்டவணைகளில் உறுப்புப் பத்திகளின் எண்ணிக்கையை இரட்டிப்பாக்கும். RISC-V முன்னணி தொகுப்பிகளின் (compiler) ஏற்கெனவே உள்ள இலக்கும் ஆகும்; எனவே guest நிரல்கள் இதற்கெனவே உருவாக்கப்பட்ட மொழியில் எழுதப்பட்ட நிரல்களாக அல்லாமல், சாதாரணமாகத் தொகுக்கப்பட்ட இருமக் கோப்புகளாக இருக்கின்றன.
ஆதாரம்: docs/zkvm.md §2; research/docs/01-isa.md (‘ஏன் RV32, RV64 அல்ல’)
20. 256-பிட் புலத்துக்குப் பதிலாக Goldilocks ஏன்?
Goldilocks என்பது 64-பிட் பகாவெண்; அதன் கணிதச் செயல்பாடுகள் இயல்பான 64-பிட் CPU கட்டளைகளுடன் திறம்படப் பொருந்துகின்றன; அதன் பெருக்கல் குழுவில் FRI-க்குத் தேவைப்படும்படி இரண்டின் அடுக்கு அளவிலான பெரிய துணைக்குழு உள்ளது. 32-பிட் சொற்களுடன் சேர்ந்து, இது ஒவ்வொரு trace வரிசையையும் குறுகலாக வைக்கிறது; இதனால் மடிக்கணினியில் உற்பத்தித் தர நிரூபணம் சாத்தியமாகிறது. சிறிய புலத்தில் செயல்படுவதால் இழக்கப்படும் உறுதித்தன்மை, FRI சவால்களை நீட்டிப்புப் புலத்திலிருந்து தேர்ந்தெடுப்பதன் மூலம் மீட்கப்படுகிறது.
ஆதாரம்: docs/zkvm.md §2; randprotocol.org (செயல்திறன் பிரிவு)
21. ஒவ்வொரு opcode-க்கும் gas அளவிடுவதற்குப் பதிலாக gas அடுக்குகள் ஏன்?
Ethereum-இல் ஒவ்வொரு opcode-க்கும் gas இருப்பதற்குக் காரணம், ஒவ்வொரு நோடும் ஒவ்வொரு பரிவர்த்தனையையும் மீண்டும் செயல்படுத்துவதும், செயல்படுத்தலின் நீளம் முன்கூட்டியே வரையறுக்கப்படாததும் ஆகும். Rand-இல் எந்த நோடும் நிரலைச் செயல்படுத்துவதில்லை: அனுப்புநர் அதை சங்கிலிக்கு வெளியே ஒரு முறை செயல்படுத்துகிறார்; நோடுகள் ஒரே ஒரு STARK-ஐச் சரிபார்க்கின்றன; அதன் சரிபார்ப்புச் செலவு செய்யப்பட்ட கணிப்பைச் சார்ந்ததல்ல, அடுக்கை மட்டுமே சார்ந்தது. முடிவடைதல் அடுக்கால் நடைமுறைப்படுத்தப்படுகிறது; ஏனெனில் 2^t சுழற்சிகளுக்குள் நிற்காத செயல்படுத்தலுக்கு t அடுக்கில் எந்த நிரூபணமும் இல்லை. விலை நிர்ணயம் என்பது நிலையான தளமும் தலைப்பால் வரையறுக்கப்பட்ட gas மதிப்பீடும் ஆகும்; தொகுதித் திறன் என்பது பைட் வரவுசெலவு. gas என்பது EVM மற்றும் sBPF interpreter guest-களுக்குள் மட்டுமே, தனிப்பட்ட நிலையாகத் தோன்றுகிறது; அங்கு மூலச் சங்கிலியின் பொருள்கோளை மீளுருவாக்க அது தேவைப்படுகிறது.
ஆதாரம்: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. trace ஏன் LogUp பேருந்துகளால் இணைக்கப்பட்ட ஒன்பது அட்டவணைகளாகப் பிரிக்கப்படுகிறது?
ஒற்றைப் பெரிய அட்டவணை ஒவ்வொரு வரிசையையும் அகலமான செயல்பாட்டின் அகலத்துக்கு நிரப்ப வேண்டியிருக்கும். trace-ஐ ஒன்பது அட்டவணைகளாகப் பிரிப்பது — CPU, memory, ALU, range, nibble, Poseidon2, program, input மற்றும் public — ஒவ்வொன்றும் தனது சொந்த உயரத்துக்கு மட்டுமே நிரப்பப்படுவதால், மொத்த trace சிறியதாக இருக்கிறது. LogUp வாதங்கள் அட்டவணைகளுக்கு இடையிலான பன்மடக்குத் தொடர்புகளை நிறுவுகின்றன. Keccak மற்றும் SHA-256 அட்டவணைகள் விருப்பத்துக்குரியவை; guest தொடர்புடைய system call-ஐ அழைக்கும்போது மட்டுமே சேர்க்கப்படுகின்றன.
ஆதாரம்: docs/zkvm.md §5
23. நிரல் அழைப்பு ஏன் எட்டு வெளியீட்டுச் சொற்களை மட்டுமே வெளியிடுகிறது?
நிரல் அழைப்பு என்பது, பொது நிரல் தனிப்பட்ட உள்ளீடுகளின் மீது சரியாகச் செயல்படுத்தப்பட்டது என்பதற்கான நிரூபணம்; லெட்ஜர் ரசீதை மட்டுமே பதிவுசெய்கிறது. ஒரு முடிவு, ஒரு commitment அல்லது ஒரு தீர்மானத்தைப் பிணைக்க எட்டு 32-பிட் சொற்கள் போதுமானவை; நிலையான வெளியீட்டு அளவு, ரசீதின் வடிவம் நிரலைப் பற்றி எதையும் வெளிப்படுத்தாததை உறுதிசெய்கிறது. தற்போது வெளியீடுகள் தரவு மட்டுமே: நிரலால் தானாக மதிப்பை மாற்ற முடியாது.
ஆதாரம்: randprotocol.org/usecases (தளக் குறிப்பு); docs/confidential.md
24. அழைப்பு-உள்ளீட்டு உறை ஏன் உள்ளது?
தனிப்பட்ட உள்ளீடுகளைத் தன்னிடம் வைத்திருக்கும் அழைப்பாளர், அழைப்பு எவற்றின் மீது கணிக்கப்பட்டது என்பதைப் பின்னர் காட்ட முடியும். அழைப்பு-உள்ளீட்டு உறை, உள்ளீடுகளை குறியாக்கம் செய்து அழைப்புடன் சேர்த்துச் சேமிப்பதன் மூலம் இதை நீடித்ததாக்குகிறது; அங்கு நியமிக்கப்பட்ட தணிக்கையாளர் ஒரு விசையால் அவற்றை மறைகுறி நீக்கலாம். இது தேர்ந்தெடுத்த வெளிப்படுத்தலை — சந்தைக்கு இரகசியம், நியமிக்கப்பட்ட ஒழுங்குமுறையாளருக்குத் திறந்தது — பணப்பரிமாற்றங்களிலிருந்து நிரல் செயல்படுத்தலுக்கு விரிவாக்குகிறது.
ஆதாரம்: docs/confidential.md (‘அழைப்பு உள்ளீட்டு உறைகள்’)
25. கட்டுப்பாட்டுத் தொகுப்பு மாற்றம் ஏன் hard fork?
ஒவ்வொரு நோடும் ஒத்திசைவின்போது ஒவ்வொரு நிரூபணத்தையும் மீண்டும் சரிபார்க்கிறது; நிரூபணம் அது உருவாக்கப்பட்ட கட்டுப்பாட்டுத் தொகுப்பின் (AIR) அடிப்படையில் மட்டுமே செல்லுபடியாகும். எனவே AIR-இல் ஏற்படும் மாற்றம் செல்லுபடியாகும் சங்கிலிகளின் தொகுப்பை மாற்றுகிறது; அது நோடுக்கு நோடு ஏற்கப்படாமல், genesis வெட்டில் அறிமுகப்படுத்தப்படுகிறது.
ஆதாரம்: docs/architecture.md (‘கட்டுப்பாட்டுத் தொகுப்பு மாற்றம் ஏன் hard fork’)
26. AIR அல்லாமல் emulator ஏன் குறிப்பீடாக உள்ளது?
emulator என்பது இயந்திரத்தின் படிக்கக்கூடிய விவரக்குறிப்பு; AIR என்பது அந்த விவரக்குறிப்பைப் பல்லுறுப்புக்கோவைக் கட்டுப்பாடுகளாக எழுதிய குறியாக்கம். இரண்டும் முரண்படும்போது, வரையறையின்படி AIR-இலேயே பிழை உள்ளது. இது நெறிமுறை வரையறையை, மனிதர்கள் தணிக்கை செய்வதற்கு மிகவும் நடைமுறைக்கு உகந்த கலைப்பொருளில் வைக்கிறது.
ஆதாரம்: docs/zkvm.md §5
ஒருமனப்பாடும் நோடும்
27. chained HotStuff BFT ஏன்?
Chained HotStuff உறுதியான இறுதித்தன்மையை வழங்குகிறது: மூன்றில் இரண்டுக்கு மேற்பட்ட stake-எடையுள்ள கோரங்களுடன், ஒரு தொகுதியின் மேல் தொடர்ச்சியான மூன்று கோரம் சான்றிதழ்கள் உருவானதும் அது இறுதியாகிறது; இறுதித் தொகுதி ஒருபோதும் மறுசீரமைக்கப்படுவதில்லை. அளவிடப்பட்ட தொகுதி இடைவெளி 1.2 s; இறுதித்தன்மைக்கான நேரம் ஏறத்தாழ 3.6 s. நோக்கமிட்ட நிறுவனப் பயனர்களுக்குத் தாங்கள் பதிவுகளைச் செய்யக்கூடிய தீர்வு இறுதித்தன்மை தேவை; நிகழ்தகவு இறுதித்தன்மை கொண்ட சங்கிலி அதை வழங்குவதில்லை.
ஆதாரம்: fullnode README; randprotocol.org (செயல்திறன் பிரிவு); docs/architecture.md §6
28. நிரூபண சரிபார்ப்பு ஏன் ஒருமனப்பாட்டு சுழற்சிக்கு வெளியே உள்ளது?
நோடு ஒவ்வொரு STARK-ஐயும் பரிவர்த்தனையை அனுமதிக்கும்போதே (சூடான நிலையில் ஏறத்தாழ 32 ms), அதைப் பரப்புவதற்கு முன் சரிபார்க்கிறது; எனவே சரிபார்ப்பு தொகுதி முன்மொழிவின் முக்கியப் பாதையில் ஒருபோதும் இருப்பதில்லை. ஆகவே தொகுதி இடைவெளி நிரூபண அளவால் அல்லாமல் ஒருமனப்பாட்டு தாமதத்தால் தீர்மானிக்கப்படுகிறது. சரிபார்ப்புகள் செலவின் வரிசையில் அடுக்கப்பட்டுள்ளன; STARK இறுதியாகச் சரிபார்க்கப்படுகிறது; இதனால் சிதைந்த பரிவர்த்தனை மிகவும் செலவான படிக்கு முன்பே நிராகரிக்கப்படுகிறது.
ஆதாரம்: randprotocol.org; docs/architecture.md (‘இது எவ்வாறு செயல்படுகிறது’)
29. மற்றவை அனைத்தும் கவசமிடப்பட்டிருக்கும்போது validator பதிவேடு ஏன் பொதுவில் உள்ளது?
எந்த validator-கள் முன்மொழியலாம், எந்த வாக்குகள் கோரத்தை உருவாக்கும் என்பதில் அனைத்துப் பிரதிகளும் உடன்பட வேண்டும்; இதற்கு stake எடைகள் பொதுவில் இருக்க வேண்டும். எனவே பதிவேடு stake தொகைகளை வெளிப்படையாகவே வைத்திருக்கிறது. உரிமையுடனான தொடர்பு மறைந்தே இருக்கிறது: bond ஒரு கவசமிட்ட நோட்டிலிருந்து நிதியளிக்கப்படுகிறது, திரும்பப்பெறுதல் ஒன்றுக்குள் செலுத்தப்படுகிறது; இரு செயல்பாடுகளும் அந்த நோட்டு யாருடையது என்பதை வெளிப்படுத்துவதில்லை.
ஆதாரம்: docs/staking.md §1
30. ஒத்திசைக்கும் நோட், சான்றிதழ்களை நம்பாமல் ஒவ்வொரு தொகுதியையும் மீண்டும் செயல்படுத்துவது ஏன்?
தாமதமாக இணையும் நோட், ஒவ்வொரு குவாரம் சான்றிதழையும் சரிபார்க்கிறது, ஒவ்வொரு தொகுப்பு (bundle) மற்றும் அழைப்பு நிரூபணத்தையும் மீண்டும் சரிபார்க்கிறது. சங்கிலியை ஏற்கும் முன், அதன் விளைவாகக் கிடைக்கும் ரசீதுகளை ஒப்பிடுகிறது. செல்லுபடித்தன்மை கையொப்பங்களால் மட்டுமின்றி நிரூபணங்களாலும் நிறுவப்படுவதால், கையொப்பங்களால் மட்டுமே பாதுகாக்கப்படும் சங்கிலிகளைப் பாதிக்கும் நீண்டகாலத் தாக்குதல்களுக்கு (long-range attacks) இந்த நடைமுறை உள்ளாவதில்லை. வரலாற்றிலிருந்து நிரூபணங்களை நீக்குவது இந்த உத்தரவாதத்தை அகற்றிவிடும் என்பதால் அந்த வழி நிராகரிக்கப்பட்டது.
மூலம்: docs/architecture.md; docs/aggregation.md (அறிமுகம்)
31. நிரூபணம் 1 MB-ஐ விஞ்சும்போதும் தொகுதி வரம்பை 4 MiB-ஆக வைத்திருப்பது ஏன்?
வரம்பு நிலையானதாக இருந்தால் தொகுதியின் அளவு அதிகரிக்க முடியாது. தேவை கொள்ளளவைத் தாண்டும்போது, அதற்குப் பதிலாக செயல்திறனே வரம்புக்குள்ளாகிறது (80-query சுயவிவரத்தில் ஒரு தொகுதிக்கு மூன்று கவசப்படுத்தப்பட்ட பரிமாற்றங்கள்). கட்டுப்பாடற்ற தொகுதி வளர்ச்சியைவிட, செயல்திறன் வரம்பே பாதுகாப்பான தோல்வி முறை எனக் கருதப்பட்டது. வரம்பை உயர்த்துவதற்கோ சவுண்ட்னெஸ் அளவைக் குறைப்பதற்கோ பதிலாக, தொகுதி அளவிலான ஒருங்கிணைப்பு, அதாவது ஒரு தொகுதிக்கு ஒரு சுழல்நிலை (recursive) நிரூபணம், தீர்வாகத் தேர்ந்தெடுக்கப்பட்டது.
மூலம்: docs/block-space.md §1, §6
32. டெஸ்ட்நெட் (testnet) வரலாற்றை ஒரு நாளுக்கு மட்டும் குறைப்பது ஏன்?
18 Dilithium2 கையொப்பங்களைக் கொண்ட குவாரம் சான்றிதழ் ஏறத்தாழ 44 KB அளவுடையது, மேலும் ஒவ்வொரு தொகுதிக்கும் இரண்டு முறை சேமிக்கப்படுகிறது. பெரும்பாலும் வெற்றுத் தொகுதிகள் ஒவ்வொரு 1.4 s-க்கும் உருவாகும்போது, இது ஒரு நோடுக்கு நாளொன்றுக்கு ஏறத்தாழ 6.6 GB ஆனது. நோட் வட்டுகள் நிரம்பின, உயரம் 248,953-இல் சங்கிலி குவாரத்தை இழந்தது. testnet முழு நோட்கள் இப்போது ஒரு நாள் வரலாற்றை வைத்திருக்கின்றன, ஒரேயொரு காப்பக நோட் முழு வரலாற்றையும் வைத்திருக்கிறது, mainnet நோட்கள் அனைத்தையும் வைத்திருக்கும். லெட்ஜர் நிலை, அதாவது மரம், nullifier தொகுப்பு, பதிவேடு மற்றும் நிரல்கள், ஒருபோதும் நீக்கப்படுவதில்லை.
மூலம்: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. libp2p ஏன்?
நோட், Noise மற்றும் Yamux உடன் TCP; பரிவர்த்தனைகள் மற்றும் வாக்குகளுக்கு gossipsub; நோட் கண்டறிதலுக்கு தொடக்கப் பட்டியலுடன் (bootstrap list) Kademlia; உள்ளூர் வலையமைப்புகளில் mDNS; தொகுதி ஒத்திசைவுக்கு request-response ஆகியவற்றைப் பயன்படுத்துகிறது. இவை தரப்படுத்தப்பட்ட, பரவலாகப் பயன்பாட்டிலுள்ள கூறுகள். எனவே சொந்த செயலாக்கங்களைப் பராமரிப்பதற்குப் பதிலாக, நோட் அவற்றின் நோட் மதிப்பீடு (peer scoring), மீண்டும் இணைதல் மற்றும் போக்குவரத்து மேம்படுத்தல்களைப் பெறுகிறது.
மூலம்: fullnode README (networking row)
நிரூபண உருவாக்கச் சந்தையும் ஒருங்கிணைப்பும்
34. தொகுதி அளவிலான நிரூபண ஒருங்கிணைப்பு ஏன்?
ஒவ்வொரு தொகுப்பும் ஏறத்தாழ 1.3 MB அளவுள்ள தனது சொந்த நிரூபணத்தைக் கொண்டிருந்தால், தொகுதி இடம் தொகுப்புகளின் எண்ணிக்கைக்கு நேர்விகிதத்தில் வளரும். அனைத்து N தொகுப்பு நிரூபணங்களையும் சரிபார்க்கும் ஒரு தொகுதிக்கு ஒரு சுழல்நிலை STARK, சங்கிலியில் உள்ள நிரூபணச் செலவை N-ஐச் சாராமல் நிலையாக வைக்கிறது. வேலிடேட்டர்கள் ஒரே ஒருங்கிணைந்த நிரூபணத்தை (வெப்பமான நிலையில் ஏறத்தாழ 16 ms) CPU-வில் சரிபார்க்கிறார்கள்; எனவே சாதாரண வன்பொருளாலும் சரிபார்க்க முடியும். அதேநேரத்தில் GPU-க்கள் கொண்ட ஒருங்கிணைப்பாளர்கள், கட்டணங்களின் நிரூபணப் பங்கு மற்றும் தொகுதி மானியத்துக்காக, அனுமதி தேவைப்படாத தனிச் சந்தையில் போட்டியிடுகிறார்கள்.
மூலம்: docs/aggregation.md §1
35. வேலிடேட்டர், ஒருங்கிணைப்பாளர், ஒப்படைக்கப்பட்ட நிரூபிப்பாளர் என மூன்று பங்குகள் ஏன்?
இந்த மூன்று பங்குகளுக்கும் வெவ்வேறு வன்பொருள் தேவைகள் உள்ளன, மேலும் அவர்களுக்கு வெவ்வேறு தரப்புகள் பணம் செலுத்துகின்றன. வேலிடேட்டர் CPU-வில் பரிவர்த்தனைகளை வரிசைப்படுத்தி சரிபார்க்கிறார்; கட்டணங்களின் சரிபார்ப்புப் பங்கிலிருந்து அவருக்குப் பணம் வழங்கப்படுகிறது. ஒருங்கிணைப்பாளர் GPU-வில் தொகுதி சுழல்நிலை நிரூபணத்தை உருவாக்குகிறார்; நிரூபணப் பங்கு மற்றும் மானியத்திலிருந்து அவருக்குப் பணம் வழங்கப்படுகிறது. ஒப்படைக்கப்பட்ட நிரூபிப்பாளர், தனது சாதனத்தால் (தொலைபேசி அல்லது உலாவி) அது இயலாத அனுப்புநருக்காக ஒரு தொகுப்பு நிரூபணத்தை உருவாக்குகிறார்; அந்த அனுப்புநர் அவருக்குத் தனிப்பட்ட முறையில் பணம் செலுத்துகிறார். பங்குகளைப் பிரிப்பது சரிபார்ப்பைக் குறைந்த செலவில் வைத்திருக்கிறது, நிரூபண உருவாக்கத்தைப் போட்டித்தன்மை கொண்டதாக்குகிறது.
மூலம்: docs/prover.md §1
36. ஒப்படைக்கப்பட்ட நிரூபிப்பாளர் நிதியைத் திருட முடியாதது ஏன்?
பிரிக்கப்பட்ட அங்கீகாரத்தில் (split authorisation), நிரூபிப்பாளர் பார்வை விசை nk-ஐப் பெறுகிறார், ஆனால் செலவு விசை sk-ஐப் பெறுவதில்லை. தொகுப்பு நிரூபணம் c = H(AUTH, nk || salt) என்பதற்கு உறுதியளிக்கிறது (commit), அதே c-க்கு sk பற்றிய அறிவை வாலட்டின் தனி அங்கீகார நிரூபணம் வெளிப்படுத்துகிறது. sk இல்லாமல், நிரூபிப்பாளரால் தொகுப்பு நிரூபணத்தைக் கணக்கிட முடியும், ஆனால் செல்லுபடியாகும் அங்கீகாரத்தை உருவாக்க முடியாது; மேலும் திருப்பி அனுப்பப்பட்ட நிரூபணத்தைச் சமர்ப்பிக்கும் முன் வாலட் சரிபார்க்கிறது.
மூலம்: docs/shielded.md (split authorisation); docs/prover.md §8
பாலமும் zUSD-யும்
37. புதிய ஸ்டேபிள்காயினை வெளியிடுவதற்குப் பதிலாக USDT/USDC-ஐ அவற்றின் சொந்தச் சங்கிலிகளில் பூட்டுவது ஏன்?
Rand-இல் நேரடி வெளியீடு செய்தால், இருப்புத் திறன் வெளியீட்டாளர்களின் செயல்படுத்தல் முடிவுகளைச் சார்ந்ததாகிவிடும்; அவை திட்டத்தின் கட்டுப்பாட்டுக்கு வெளியே உள்ளவை. Ethereum, BSC, Tron மற்றும் Solana ஆகியவற்றில் USDT மற்றும் USDC-ஐப் பூட்டுவது, இந்தச் சொத்துகள் ஏற்கனவே புழங்கும் சங்கிலிகளிலிருந்தே இருப்புகளைப் பெறுகிறது, புதிய வெளியீட்டாளர் எவரையும் அறிமுகப்படுத்துவதில்லை: ஒவ்வொரு zUSD அலகும், பொதுவாகப் படிக்கக்கூடிய காவல் ஒப்பந்தத்தில் (custody contract) வைக்கப்பட்டுள்ள USDT அல்லது USDC மீதான உரிமைக்கோரல் ஆகும்.
மூலம்: randprotocol.org (reserve section)
38. t-of-n காவலர் தொகுப்பு (guardian set) ஏன், அதை வெளிப்படையாகக் கூறுவது ஏன்?
மற்றொரு சங்கிலியில் பூட்டுதல் நடந்தது என்பதற்கு Rand-க்குக் கிடைக்கும் ஒரே சான்று சான்றளிப்பு (attestation) மட்டுமே; எனவே அது ஒரு வரம்புக் குழுவால் (threshold group) கையொப்பமிடப்பட வேண்டும். செல்லுபடியாகும் சான்றளிப்புக்கு, காவலர்களில் மூன்றில் இரண்டு பங்குக்கும் அதிகமானோரின் கையொப்பங்கள் தேவை. இதன் விளைவாக உருவாகும் நம்பிக்கை அனுமானம் வெளிப்படையாகக் கூறப்படுகிறது. பயனுள்ள உத்தரவாதம் என்பது இருப்புக் கடனடைப்புத் திறன் மற்றும் பாலத்தின் நேர்மை ஆகிய இரண்டில் பலவீனமானது; t காவலர்கள் கொண்ட கூட்டணி, அதற்கு இணையான பூட்டுதல் இல்லாமலேயே நாணயம் உருவாக்க (mint) அனுமதி வழங்க முடியும்; அபாயம் ஒவ்வொரு சங்கிலியிலும் உள்ள காவல் இருப்பால் வரையறுக்கப்படுகிறது. இந்த அனுமானமே முதலில் பாலம் கட்டுவதற்கு எதிரான வாதமாக இருந்தது. அது திரும்பப் பெறப்படவில்லை, இருப்புத் திறனுக்கு ஈடாக ஏற்றுக்கொள்ளப்பட்டுள்ளது.
மூலம்: randprotocol.org (reserve section, ‘What this costs’)
39. ECDSA சான்றளிப்புடன் கூடுதலாக Dilithium2 இணைக் கையொப்பம் ஏன்?
மூலச் சங்கிலிகளில் லேட்டிஸ் கையொப்ப சரிபார்ப்பி எதுவும் இல்லை; எனவே அந்தச் சங்கிலிகளில் வெளியீடுகள் பாரம்பரிய ECDSA-வால் பாதுகாக்கப்படுகின்றன, அபாயம் காவல் இருப்பு மற்றும் வரம்புகளால் கட்டுப்படுத்தப்படுகிறது. காவலர்களிடமிருந்து Rand லெட்ஜர் ஏற்கும் ஒவ்வொரு செய்தியும், அதாவது வைப்புகள் மற்றும் காவலர் தொகுப்பு சுழற்சிகள், அதே காவலர்களின் Dilithium2 கையொப்பங்களின் குவாரத்தையும் கூடுதலாகக் கொண்டிருக்க வேண்டும். எனவே வெளிப்புற முனைகள் அவ்வாறு இல்லாதபோதும், நாணய உருவாக்க (mint) பாதை குவாண்டத்துக்குப் பிந்தையது (post-quantum). இணைக் கையொப்பங்கள் சான்றளிப்புடன் சேர்த்து அனுப்பப்படுகின்றன, ஏற்கனவே பயன்பாட்டிலுள்ள ஒப்பந்தங்களில் எந்த மாற்றமும் தேவையில்லை.
மூலம்: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. வைப்பு நோட்டின் மறைப்புக் காரணி (blinding) தேர்ந்தெடுக்கப்படாமல் தருவிக்கப்படுவது ஏன்?
முன்பு, ரிலேயர் சான்றளிப்பைச் சமர்ப்பிக்கும் வரை வைப்பு நோட்டின் உறுதிப்பாடு (commitment) தீர்மானிக்கப்படவில்லை; எனவே இரண்டு ரிலேயர்கள் ஒரே சான்றளிப்பை வெவ்வேறு நோட்டுகளுடன் சமர்ப்பிக்க முடிந்தது. மறைப்புக் காரணி r-ஐச் சான்றளிப்பிலிருந்து தீர்மானகரமாகத் தருவிப்பது உறுதிப்பாட்டை நிலைநிறுத்துகிறது; எனவே போட்டியிடும் சமர்ப்பிப்புகள் ஒரே உறுதிப்பாட்டில் மோதுகின்றன, வைப்பை இருமுறை உருவாக்க (mint) முடியாது.
மூலம்: docs/bridge.md (F1, chain 14)
41. Tron-இல் பூட்டப்பட்ட USDT, Ethereum-இல் USDT ஆக வெளியேற முடிவது ஏன்?
zUSD மாற்றத்தக்கது (fungible): ஒவ்வொரு அலகும் மொத்த இருப்பின் மீதான உரிமைக்கோரல், அது நுழைந்த சங்கிலியின் மீதானது அல்ல. நுழைவையும் வெளியேற்றத்தையும் பிரிப்பது, இலக்குச் சங்கிலியில் போதுமான இருப்புகள் இருக்கும் வரையில், தேவை உள்ள இடத்துக்கு நீர்மைத்தன்மை (liquidity) நகர அனுமதிக்கிறது. S ≤ Σ_c R_c என்ற மாறாநிலை, அதாவது மொத்த வழங்கல் ஒவ்வொரு சங்கிலியின் இருப்புகளின் கூட்டுத்தொகைக்குள் வரம்பிடப்படுவது, ஒவ்வொரு நிலை மாற்றத்தாலும் பாதுகாக்கப்படுகிறது என்பதை ஸ்டேபிள்காயின் ஆய்வறிக்கை நிரூபிக்கிறது.
மூலம்: randprotocol.org (reserve section)
42. கவசப்படுத்தல் பங்கீட்டை மறைக்கிறது, ஆனால் அளவை மறைக்காதது ஏன்?
மொத்த zUSD வழங்கல் டோக்கன் பதிவேட்டில் பொதுவாக உள்ளது, ஒவ்வொரு சங்கிலியின் இருப்பும் பொது இருப்பாக உள்ளது; எனவே கடனடைப்புத் திறனை எவரும் சரிபார்க்கலாம். மறைக்கப்படுவது உரிமையாளர்களிடையே உள்ள உடைமைகளின் பங்கீடு மட்டுமே. ஒரு வரம்பு பொருந்தும்: நான்கு இருப்புகளையும் ஒரே கணத்தில் அணுக்கமாகக் (atomically) கவனிக்க முடியாது; எனவே அந்தச் சங்கிலிகளுக்கு, இந்தச் சரிபார்ப்பு கடனடைப்பின்மையைத் தடுப்பதற்குப் பதிலாக, நிகழ்ந்த பின்னரே கண்டறிகிறது.
மூலம்: randprotocol.org (reserve section)
43. எரிப்பு (burn) மட்டும் தனது சொத்தைக் குறிப்பிடும் ஒரே பரிவர்த்தனையாக இருப்பது ஏன்?
எரிப்பு ஒரு குறிப்பிட்ட சங்கிலியில் ஒரு குறிப்பிட்ட சொத்தை வெளியிடுகிறது; எனவே எந்தச் சொத்து, எந்தச் சங்கிலி என்பதைக் காவல் ஒப்பந்தம் அறிய வேண்டும். மற்ற ஒவ்வொரு பரிவர்த்தனையும் அடையாளம் காணப்படாத சொத்தை மாற்றுகிறது. அனுப்புநரே பயனாளியாக இருக்கும் ஒரே பாலப் பரிவர்த்தனை எரிப்பு என்பதால், அது பாலக் கட்டணத்தையும் சுமக்கிறது.
மூலம்: docs/architecture.md; docs/shielded.md §2
இணக்கமும் வெளிப்படுத்தலும்
44. ‘அனைவரிடமிருந்தும் தனிப்பட்டது’ என்பதற்குப் பதிலாகப் பார்வை விசைகள் ஏன்?
Tornado Cash வழக்கு காட்டுவதுபோல், விசாரணைக்கு உட்பட்ட தரப்பின் ஒத்துழைப்பைச் சார்ந்து வெளிப்படுத்தல் அமையும் தனியுரிமை அமைப்புகளை ஒழுங்குமுறை அமைப்புகள் ஏற்கவில்லை. எனவே Rand வெளிப்படுத்தலை நெறிமுறைப் பொருளாகக் கருதுகிறது. உரிமையாளர் அல்லது ஒழுங்குமுறைக்கு உட்பட்ட இடைத்தரகர் பார்வை விசையை வைத்திருக்கிறார்; சட்டபூர்வ கோரிக்கையில் குறிப்பிடப்பட்ட பரிவர்த்தனைகளைத் தணிக்கையாளர் மறைகுறியீடு நீக்க முடியும்; வர்த்தக உத்தியை வெளிப்படுத்தாமல், எதிர்த்தரப்பு மற்றும் தொகையை வெளிப்படுத்தும் வரம்புக்குட்பட்ட விசைகளே வடிவமைப்பு இலக்கு. சம்பளப் பட்டியல் போன்ற பயன்பாடுகளுக்கு, இந்தத் தணிக்கைத்தன்மை ஒரு வரம்பு அல்ல, ஒரு தேவையாகும்.
மூலம்: randprotocol.org/usecases (regulation section; payroll case)
45. வெளிச்செல்லும் பார்வை விசை உள்வரும் விசையிலிருந்து தனியாக இருப்பது ஏன்?
இந்தப் பிரிப்பு, பெறுநரின் வரலாற்றை அணுகாமலேயே, தான் எதைச் செலுத்தினோம் என்பதை அனுப்புநர் நிரூபிக்க அனுமதிக்கிறது; மறுதலையும் அவ்வாறே. வெளிச்செல்லும் பார்வை விசை ovk, வாலட் அனுப்பிய உறைகளை மறைகுறியீடு நீக்குகிறது; ML-KEM டிகேப்சுலேஷன் விசை தனக்கு அனுப்பப்பட்ட உறைகளை மறைகுறியீடு நீக்குகிறது; ஒவ்வொரு பரிவர்த்தனைக்குமான விசை, சரியாக ஒரு வெளியீட்டை மூன்றாம் தரப்புக்கு வெளிப்படுத்துகிறது.
மூலம்: docs/shielded.md §1–2
அறியப்பட்ட வரம்புகள்
46. நிரூபணங்கள் இன்று எதைக் கசியவிடுகின்றன, அது ஏன் ஆவணப்படுத்தப்பட்டுள்ளது?
2026-09-27 மதிப்பாய்வு, v1 guest-இன் (chains 14–15) கீழ் ஒவ்வொரு தொகுப்பு நிரூபணமும், எந்த உள்ளீட்டு இடங்கள் உண்மையான நோட்டுகளைக் கொண்டுள்ளன என்பதையும், செலவிடப்பட்ட ஒவ்வொரு இலை சுட்டெண்ணின் ஹேமிங் எடையையும் (Hamming weight) வெளிப்படுத்துகிறது எனக் கண்டறிந்தது. காரணம் இருவகைப்பட்டது: ஒவ்வொரு அட்டவணைக்குமான LogUp மொத்தங்கள் மறைப்பு இல்லாமல் வெளியிடப்படுகின்றன, மேலும் உள்ளீடு போலியானதா என்பதைப் பொறுத்து guest-இன் கட்டுப்பாட்டு ஓட்டம் கிளைக்கிறது. தீர்வு, கிளைகள் இல்லாத guest (v2); அது அடுத்த genesis-இல் தேர்ந்தெடுக்கப்படும். இந்த வலையமைப்பு ஒரு testnet என்பதாலும், ஆவணங்கள் அதன் தணிக்கைப் பதிவாகச் செயல்படுவதாலும் இந்தக் கண்டுபிடிப்பு வெளியிடப்படுகிறது.
மூலம்: docs/shielded.md (‘What the proofs leak today’)
47. நிலை வளர்ச்சிக்கு விலை குறைவாக நிர்ணயிக்கப்பட்டுள்ளது ஏன்?
Ethereum சேமிப்பு எழுதல்களுக்கு விலை நிர்ணயிக்கிறது; ஏனெனில் சேமிக்கப்பட்ட நிலை ஒவ்வொரு நோடுக்கும் நிரந்தரச் செலவை ஏற்படுத்துகிறது. commitment tree, nullifier set, நிரல் சேமிப்பு ஆகியவற்றின் வளர்ச்சிக்கு Rand தற்போது ஒரு சொல்லுக்கான வரிசைப்படுத்தல் கட்டணம் (per-word deployment fee), நிலையான bundle கட்டணம் ஆகிய இரண்டின் மூலமாக மட்டுமே விலை நிர்ணயிக்கிறது. இது testnet-க்குப் போதுமானது; ஆனால் mainnet-க்கு முன் தீர்க்கப்பட வேண்டிய திறந்த விலை நிர்ணயக் கேள்வியாகப் பதிவு செய்யப்பட்டுள்ளது. அதைத் தீர்ப்பதற்கு ஒவ்வொரு opcode-க்கும் தனியாக அளவீடு செய்ய வேண்டியதில்லை.
மூலம்: docs/fees.md §3 (caveats)
48. இதுவரை சுயாதீனத் தணிக்கை ஏன் முடிக்கப்படவில்லை?
இந்த நெறிமுறை, குழுவால் இயக்கப்படும் testnet-இல் தீவிர மேம்பாட்டில் உள்ளது; வடிவமைப்பு நிலைபெறுவதற்கு முன் மேலும் constraint தொகுப்புகளும் chain வெட்டுகளும் எதிர்பார்க்கப்படுகின்றன. இணையதளம் ஒவ்வொரு பக்கத்திலும் இதைத் தெரிவிக்கிறது. இறுதியில் நடைபெறவிருக்கும் வெளிப்புறத் தணிக்கைக்கு முழுமையான பதிவு கிடைக்கும்படி, உள்ளக தணிக்கைச் சுற்றுகள் (v3–v5) docs/consensus.md-லும் வடிவமைப்பு விவரக்குறிப்புகளிலும் வெளியிடப்பட்டுள்ளன.
மூலம்: randprotocol.org (footer); docs/consensus.md