பரிவர்த்தனைகளும் செயல்களும்

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

பரிவர்த்தனை

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

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

Word8 என்பது எட்டு லிட்டில்-எண்டியன் u32 சொற்கள்; இது 64 சிற்றெழுத்து ஹெக்ஸ் எழுத்துகளாகக் காட்டப்படுகிறது. அனுப்புகை வடிவம் bincode-இன் இயல்புநிலை அமைப்புகளுடன் (நிலையான அகல முழு எண்கள், 8-பைட் நீள முன்னொட்டுகள், u32 enum குறிச்சொற்கள்) கூடிய bincode(Transaction) ஆகும்; rand_sendTransaction அதை ஹெக்ஸ் வடிவில் ஏற்கிறது. பரிவர்த்தனையின் மீது கையொப்பமும் இல்லை, அனுப்புநர் புலமும் இல்லை: ஒரு தொகுப்பு தன் நிரூபணங்களாலேயே தன்னை அங்கீகரித்துக்கொள்கிறது (தொகுப்பு நிரூபணம், மேலும் chain 17 முதல் அதனுடன் உள்ள அங்கீகார நிரூபணம்); கையொப்பமிடப்பட்ட செயல் அந்தக் கையொப்பத்தைத் தனக்குள்ளேயே கொண்டுள்ளது. மறுபயன்பாட்டுப் பாதுகாப்பு என்பது தொகுப்புகளுக்கு செல்லாக்கித் தொகுப்பு, கையொப்பமிடப்பட்ட ஸ்டேக்கிங் செயல்களுக்குப் பதிவேட்டில் உள்ள ஒவ்வொரு உறுதிப்படுத்துநருக்குமான நான்ஸ், TokenMint மற்றும் SetAuthority-க்கு ஒவ்வொரு டோக்கனுக்குமான mint_nonce, பாலத்தின் ஆளுகைச் செயல்களுக்கு அதன் pause_nonce மற்றும் list_nonce ஆகியவை.

ஒரு பரிவர்த்தனை அதிகபட்சம் ஒரு தொகுப்பைக் கொண்டிருக்கும்; தொகுப்பில்லாச் செயல் அல்லாத ஒவ்வொரு செயலும் சரியாக ஒரு தொகுப்பைக் கொண்டிருக்கும். தொகுப்பின் 0–1 இடங்கள் ஒரு தனிப்பட்ட சொத்தையும் 2–3 இடங்கள் RAND-ஐயும் கொண்டுள்ளன; எனவே ஒரே நிரூபணம் ஒரு டோக்கனை நகர்த்தி அதன் RAND கட்டணத்தையும் செலுத்துகிறது. முந்தைய வடிவமைப்பின் இரு-தொகுப்புப் பால எரிப்பு நீக்கப்பட்டுவிட்டது: ஒரு எரிப்பு என்பது ஒரே தொகுப்பு (குறிப்புகள்).

rand பணப்பை இவை அனைத்தையும் randprotocol_client::wallet::{send, submit} மூலம் உருவாக்குகிறது: உள்ளீடுகளைத் தேர்ந்தெடுத்தல், நங்கூரத்தைப் பெறுதல், பணப்பையின் சொந்த மரப் பிரதியிலிருந்து சாட்சிகளைக் கணக்கிடுதல், வெளியீடுகளை உருவாக்கி நான்கு உறைகளையும் முத்திரையிடுதல், பரிவர்த்தனையின் பிணைப்பைப் பெறுதல், தொகுப்பையும் அங்கீகார நிரூபணத்தையும் நிரூபித்தல், தொகுப்பு நிரூபணம் வெளியிடும் டைஜெஸ்டைச் சரிபார்த்தல், சமர்ப்பித்தல்.

பரிவர்த்தனைப் பிணைப்பு

ஒரு பரிவர்த்தனைக்குக் கையொப்பம் இல்லை; ஒரு தொகுப்பின் நிரூபணம் அந்தத் தொகுப்பின் சொந்த டைஜெஸ்டுக்கு மட்டுமே பொறுப்புறுதி அளிக்கிறது: நங்கூரம், செல்லாக்கிகள், பொறுப்புறுதிகள், கட்டணம், எரிப்புப் புலங்கள், time. chain 13 வரை, நிரூபிக்கப்பட்ட தொகுப்பை அது உடன்வந்த செயலுடனோ அதன் உறைகளுடனோ எதுவும் பிணைக்கவில்லை; எனவே ஒரு பரிவர்த்தனையைப் பார்த்த எவரும் நிரூபணத்தின் ஒவ்வொரு பைட்டையும் வைத்துக்கொண்டு மீதியை மாற்ற முடிந்தது: ஒரு BridgeBurn-இன் இலக்கு, ஒரு Bond-இன் உறுதிப்படுத்துநர், ஓர் உறை. chain 14 முதல் ஒவ்வொரு தொகுப்பு நிரூபணமும் பரிவர்த்தனையின் பிணைப்பின் மீது உருவாக்கப்பட்டு, அதற்கு எதிராகச் சரிபார்க்கப்படுகிறது:

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

இங்கு ' என்பது தொகுப்பு நிரூபணத்தின் ஒவ்வொரு பைட் சரமும் வெற்று வெக்டரால் மாற்றப்படுவதைக் குறிக்கிறது: bundle.proof, chain 17 முதல் bundle.auth_proof, மற்றும் ஒரு Aggregate-இன் proof. மற்ற அனைத்தும் உள்ளே அடங்கும்: auth_commit, நான்கு உறைகளும், ஒவ்வொரு எரிப்புப் புலமும், ஓர் இலக்கு, ஓர் உறுதிப்படுத்துநர், ஒரு பெறுநர், கையொப்பங்கள், காப்பாளர் சான்றளிப்பும் அதன் Dilithium2 இணைக் கையொப்பங்களும், ஒரு Call-இன் சொந்த நிரூபணம். இந்த எட்டுச் சொற்களும் நிரூபணத்தின் பொது உள்ளீட்டுப் பகுதியில் செல்கின்றன; அதன் டைஜெஸ்ட் H_PUB-ஐச் சுற்று ஏற்கனவே பிணைக்கிறது; எனவே இந்தத் திருத்தத்துக்கு விருந்தினர் நிரலிலோ சுற்றிலோ எந்த மாற்றமும் தேவைப்படவில்லை. கணு Machine::verify_public(hc_bundle, binding, proof)-ஐ இயக்குகிறது; வேறு எந்தப் பொது உயரத்தை அறிவிக்கும் தொகுப்பு நிரூபணத்தையும் மறுக்கிறது (public height not the transaction binding's). Transaction::binding என்பது பணப்பை நிரூபிப்பதற்கு முன்பும் பேரேடு சரிபார்ப்பதற்கு முன்பும் அழைக்கும் ஒரே செயல்பாடு. chain 17 முதல் அங்கீகார நிரூபணமும் அதே எட்டுச் சொற்களின் மீது உருவாக்கப்பட்டு அவற்றுக்கு எதிராகச் சரிபார்க்கப்படுகிறது; எனவே அதையும் வேறொரு பரிவர்த்தனைக்கு நகர்த்த முடியாது.

Chain 20 ஜெனிசிஸ் ஹாஷைப் பிணைக்கிறது. chain 19 வரை, பிணைப்பும் தொகுப்பில்லாச் செயல்களின் கையொப்பமிடப்பட்ட செய்திகளும் chain id-ஐ மட்டுமே உள்ளடக்கின; எனவே ஒரே chain id-ஐப் பகிரும் இரு சங்கிலிகள் (ஒரு மறு-வெட்டு, ஒரு தனிப்பட்ட பிரதி) ஒன்றின் நிரூபணங்களையும் கையொப்பங்களையும் மற்றொன்று ஏற்றிருக்கும். Chain 20-இன் ஜெனிசிஸ் binding_domain: 1 என அமைக்கிறது (v0.6.8, audit v6 BIND-1; crates/randprotocol-core/src/types/binding.rs). அதன்பின் ஜெனிசிஸ் ஹாஷ் ஒவ்வொரு முன்படிமத்தையும் ஒரு பதிப்பு உயர்ந்த குறிச்சொல்லின் கீழ் தொடங்குகிறது: இரு பிணைப்புகளுக்கும் rand-tx-bind-2 மற்றும் rand-call-bind-2; அதே போல ஃபாசெட் உருவாக்கத்துக்கு (rand-mint-3), Unbond மற்றும் Withdraw-க்கு (rand-unbond-2, rand-withdraw-2), RPL உருவாக்க மற்றும் அதிகாரச் செய்திகளுக்கு (rand-rpl-mint-2, rand-rpl-authority-2), திரட்டிச் செயல்களுக்கும் பாலத்தின் ஆளுகைச் செய்திகளுக்கும். அத்தகைய சங்கிலியில் உறுதிப்படுத்துநர் பதிவு எப்போதும் v2 செய்தியே (ஜெனிசிஸ், சங்கிலி, முகவரி, செலுத்துகை). ஒரு சங்கிலிக்காக நிரூபிக்கப்பட்டதோ கையொப்பமிடப்பட்டதோ எதுவும், அதன் chain id எதுவாயினும், மற்றொரு சங்கிலியில் சரிபார்க்கப்படாது. பிணைப்புச் சொற்கள் பொது உள்ளீடு என்பதால் விருந்தினர் நிரலோ சரிபார்ப்பாளர் விசையோ மாறவில்லை. v0.6.8-க்கு முந்தைய பணப்பை இன்னும் chain-id வடிவத்துக்கு எதிராக நிரூபிக்கிறது; அது chain 20-இல் மறுக்கப்படுகிறது. rand_getLimits மற்றும் rand_status binding_domain-ஐ வழங்குகின்றன (chain 20-இல் 1, புலம் இல்லையெனில் 0).

ஜெனிசிஸ் hardening_v6-இன் கீழ் (chains 16 முதல் 20 வரை) ஒரு Call-இன் சொந்த நிரூபணமும் பிணைக்கப்படுகிறது; அதே கட்டமைப்பிலான, தனக்கென்ற களத்தின் கீழ் உள்ள இரண்டாவது டைஜெஸ்ட் மூலம், தொகுப்பின் நிரூபணங்களுடன் அழைப்பு நிரூபணமும் வெறுமையாக்கப்பட்டு:

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

chain 20-இல் குறிச்சொல் rand-call-bind-2; மேலே உள்ளதுபோல ஜெனிசிஸ் ஹாஷ் முன்படிமத்தைத் தொடங்குகிறது. ஒரு Invoke-இன் நிரூபணமும் அதே முறையில் பிணைக்கப்படுகிறது; அதன் அறிவிக்கப்பட்ட நிலைமாற்றம் முன்படிமத்தில் வைக்கப்படுகிறது; எனவே பரிவர்த்தனை கொண்டுள்ள நிலை மாற்றம், செலுத்துகைகள், பெறுநர்கள் ஆகியவற்றுக்குச் சரியாக நிரூபணம் பொறுப்புறுதி அளிக்கிறது.

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

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

பரிவர்த்தனை அடையாளம்

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

இங்கு view என்பது, தொகுப்பின் proof பைட்டுகள் blake3(proof)-ஆலும் (proof_hash) அதன் auth_proof பைட்டுகள் blake3(auth_proof)-ஆலும் (auth_proof_hash, auth_commit-க்குப் பின்னர்; auth_commit உள்ளது உள்ளபடியே சேர்கிறது) மாற்றப்பட்ட பரிவர்த்தனை; மற்ற ஒவ்வொரு புலமும் மாற்றமின்றி அப்படியே. chain 16 வரை களம் rand-txid-2 ஆக இருந்தது, இரு அங்கீகாரப் புலங்கள் இல்லாமல்; chain 17-உடன் ஒவ்வொரு பரிவர்த்தனை அடையாளமும் மாறியது. நிரூபணத்தை அதன் டைஜெஸ்ட் மூலம் ஹாஷ் செய்வதால்தான் கத்தரிக்கப்பட்ட தொகுப்பு (தொகுதித் திரட்டல், chain 20-இல் செயல்பாட்டில் இல்லை) தன் மூல வடிவத்தின் அதே அடையாளத்தைத் தக்கவைக்கிறது; கத்தரிக்கப்பட்ட தொகுப்பு தன் அங்கீகார நிரூபணத்தைத் தக்கவைக்கிறது. தொகுப்பில்லாப் பரிவர்த்தனை தன் பைட்டுகளை உள்ளது உள்ளபடியே ஹாஷ் செய்கிறது. அதே அடையாளமே மெம்பூல், ரசீதுகள், ஒவ்வொரு RPC தேடலுக்கும் திறவுகோலாக உள்ளது.

ஒவ்வொரு செயலும்

Action என்பது ஒரு bincode enum வகை; குறிச்சொற்கள் அறிவிப்பு வரிசையில் உள்ளன:

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

சங்கிலி 20-இல், குறிச்சொற்கள் 0 முதல் 8 வரை, 14 முதல் 21 வரை, 28, மற்றும் 30 முதல் 33 வரை பயன்படுத்தக்கூடியவை. அதன் ஜெனிசிஸில் rules_v2 கொண்ட bridge பகுதி, tokens பகுதி, staking.admission_by_vote (குறிச்சொல் 28), bridge.rotation (குறிச்சொற்கள் 30 முதல் 32 வரை), program_state (குறிச்சொல் 33) ஆகியவை உள்ளன. குறிச்சொற்கள் 22, 23 அங்கு மறுக்கப்படுகின்றன: bridge.rotation.needs_possession-இன் கீழ், ஒரு சுழற்சி ஒவ்வொரு புதிய சாவியின் சொந்தக் கையொப்பத்தையும் கொண்டுசெல்லும் …V2 வடிவத்திலேயே இருக்க வேண்டும். அந்தப் பகுதிகள் எதுவும் இல்லாத சங்கிலி 19-இல், குறிச்சொற்கள் 0 முதல் 8 வரையும் 14 முதல் 23 வரையும் பயன்படுத்தக்கூடியவையாக இருந்தன (rules_v2 இல்லாத சங்கிலி 14, 22, 23-ஐ மறுத்தது). SlashEquivocation-க்கு staking.slashing பகுதி தேவை; சங்கிலி 20-இல் அது null. ஐந்து திரட்டுச் செயல்களுக்கும் aggregation பகுதி தேவை; சங்கிலி 20-இல் அது இல்லை (திரட்டல் மீண்டும் அளவிடப்படும் வரை, அத்தகைய பகுதியைக் கொண்ட ஜெனிசிஸில் தொடங்க ஒரு build மறுக்கிறது). ஒரு கணு இவை அனைத்தையும் வேறு எந்தச் சோதனைக்கும் முன்பாக நுழைவாயிலிலேயே மறுக்கிறது; ஆனாலும் அவை தங்கள் bincode குறிச்சொற்களை ஆக்கிரமித்திருப்பதால், குறிச்சொல் எண்களை நிலையாகக் குறியீட்டில் பதிக்கும் குறியாக்கி அவற்றையும் எண்ணிக்கையில் சேர்க்க வேண்டும். திரட்டல் வரவிருக்கும் அம்சமாக நிரூபணங்கள் பக்கத்தில் ஆவணப்படுத்தப்பட்டுள்ளது. நான்கு ஜெனிசிஸ் vesting செயல்களுக்கும் (குறிச்சொற்கள் 24 முதல் 27 வரை, v0.5.11 முதல் build-இல் உள்ளவை) vesting பகுதி தேவை; சங்கிலி 20 உட்பட எந்தச் சங்கிலியிலும் அது இருந்ததில்லை, அது இல்லாமல் அவை சேர்ப்பின்போதே மறுக்கப்படுகின்றன. குறிச்சொற்கள் 28 முதல் 33 வரை v0.6.8-இல் புதியவை, அவை கடைசியில் சேர்க்கப்பட்டுள்ளன; எனவே முந்தைய ஒவ்வொரு சங்கிலியின் வரலாறும் இன்னும் குறிவிலக்கம் செய்யப்படுகிறது.

நான்கு RPL செயல்கள் (குறிச்சொற்கள் 14 முதல் 17 வரை) ஒரு டோக்கனைப் பதிவுசெய்கின்றன, Key அதிகாரம் பெற்ற டோக்கனைக் கூடுதலாக அச்சிடுகின்றன, அதன் அச்சிடும் அதிகாரத்தைக் கைமாற்றுகின்றன அல்லது துறக்கின்றன, ஒரு இருப்பை எரிக்கின்றன; Bridge அல்லது Program அதிகாரத்தைக் குறிப்பிடும் RegisterToken மறுக்கப்படுகிறது. டோக்கன் பரிமாற்றத்துக்கெனத் தனிச் செயல் இல்லை: டோக்கன் பரிமாற்றம் என்பது None, அது RAND கொடுப்பனவிலிருந்து பிரித்தறிய முடியாதது. RPL டோக்கன்கள் பார்க்கவும். நான்கு பால ஆளுகைச் செயல்கள் (குறிச்சொற்கள் 18 முதல் 21 வரை) அச்சிடல் இடைநிறுத்தம், அதன் நீக்கம், ஜெனிசிஸுக்குப் பிறகு ஒரு பால டோக்கனையோ கூடுதல் ஆதாரச் சொத்தையோ பட்டியலிடுதல் ஆகியவை. PauseMints ஜெனிசிஸ் இடைநிறுத்தச் சாவியால் கையொப்பமிடப்படுகிறது; அந்தச் சாவியால் இடைநிறுத்த மட்டுமே முடியும்; மற்ற மூன்றுக்கும் Dilithium2 (PQ) காவலர்களின் குறைவெண் தேவை. ஒரு BridgeAttest-உம் தனது ECDSA குறைவெண்ணுடன் அத்தகைய குறைவெண்ணைக் கொண்டுசெல்கிறது. பால rules_v2-இன் கீழ், குறிச்சொற்கள் 22, 23 PQ காவலர் தொகுப்பையோ இடைநிறுத்தச் சாவியையோ மாற்றுகின்றன; ஒவ்வொன்றும் தற்போதைய தொகுப்பின் PQ குறைவெண் மற்றும் பாலத்தின் rotation_nonce-இன் கீழ். குறிச்சொற்கள் 30, 31 bridge.rotation-இன் கீழ் அதையே செய்கின்றன; அத்துடன் சுழற்சிச் செய்தியின் மீது ஒவ்வொரு புதிய சாவியின் சொந்த Dilithium2 கையொப்பத்தையும் கொண்டுசெல்கின்றன — அந்தச் சாவி கைவசம் உள்ளது என்பதற்கான நிரூபணம் அது; சங்கிலி 20-இல் ஒரு சுழற்சி நிலுவையில் உள்ளதாகப் பதிவுசெய்யப்பட்டு delay_secs, அதாவது 86,400 s கழித்து நடைமுறைக்கு வருகிறது. தற்போதைய இடைநிறுத்தச் சாவியால் கையொப்பமிடப்படும் CancelRotation (குறிச்சொல் 32), நிலுவையிலுள்ள சுழற்சியை அது நடைமுறைக்கு வரும் முன்பே கைவிடுகிறது. பாலம் பார்க்கவும்.

AdmitValidator (குறிச்சொல் 28) என்பது ஒரு புதிய சாவியை ஏற்பதற்கான சரிபார்ப்பாளர் தொகுப்பின் வாக்கு: பங்கில் மூன்றில் இரண்டு பங்குக்கு மேல் வைத்திருக்கும் சரிபார்ப்பாளர்களின் கையொப்பங்கள், முகவரிகளின் ஏறுவரிசையில். staking.admission_by_vote-இன் கீழ் (சங்கிலி 20), புதிய சரிபார்ப்பாளரைப் பதிவுசெய்யும் ஒரு Bond, அதன் முகவரி இவ்வாறு ஏற்கப்பட்டிருந்தால் அன்றி மறுக்கப்படுகிறது (ஸ்டேக்கிங்). Invoke (குறிச்சொல் 33, RPL-2) என்பது நிரலின் அறிவிக்கப்பட்ட ஒரு நிலை transition-க்கு அதன் நிரூபணம் உறுதியளிக்கும் அழைப்பு: படிக்கப்பட்ட, எழுதப்பட்ட கலங்கள், தொகுப்பின் எரிப்புப் புலங்கள் நிரலின் பெட்டகத்துக்குள் கொண்டுவருபவை, பெட்டகம் செலுத்தும் அல்லது நிரல் அச்சிடும் குறிப்புகள். அறிவிக்கப்பட்ட ஒவ்வொரு வாசிப்பும் இன்னும் செல்லுபடியாக இருந்து, இரு நிரூபணங்களும் சரிபார்க்கப்பட்டால், லெட்ஜர் அந்த நிலைமாற்றத்தைச் செயல்படுத்துகிறது (நிரல்கள்).

Deploy, Call இரண்டும் சாதாரண மறைக்கப்பட்ட பரிவர்த்தனைகளே; அவற்றின் தொகுப்பு பூஜ்ய மதிப்புள்ள சுய-பரிமாற்றம்: அழைப்பவரின் சொந்தக் குறிப்புகளிலிருந்து குறைந்தபட்சக் கட்டணத்தைச் செலுத்துவதற்காகவே அது உள்ளது; எனவே அவை யாருடையவை என்பது சங்கிலிக்கு ஒருபோதும் தெரியாது. RAND குளத்திலிருந்து burn_r வழியாக மட்டுமே வெளியேறுகிறது — ஒரு Bond-இன் பங்கு, ஒரு RegisterAggregator-இன் பிணைத்தொகை, ஒரு Invoke நிரல் பெட்டகத்துக்குள் செலுத்தும் வைப்பு — ஒரு டோக்கன், burn_asset அதைக் குறிப்பிடும் நிலையில் burn_a வழியாக மட்டுமே, ஒரு TokenBurn, BridgeBurn அல்லது Invoke-இல். வேறு எந்தச் செயலும் எதையும் எரிப்பதில்லை; burn_asset = 0 உடனும் பூஜ்யமற்ற burn_a உடனும் உள்ள தொகுப்பு எல்லா இடங்களிலும் மறுக்கப்படுகிறது.

சேர்ப்பு வரிசை

Ledger::validate_inner மலிவான சோதனைகளைச் செலவுமிக்கவற்றுக்கு முன்பாக, இந்த வரிசையில் சரிபார்க்கிறது; மெம்பூலும் பரப்புவதற்கு முன் இதே சோதனையை இயக்குகிறது; எனவே தவறான பரிவர்த்தனை ஒருமுறை, விளிம்பிலேயே மறுக்கப்படுகிறது.

1. அளவு வரம்புகள் — முழுப் பரிவர்த்தனையும் ≤ சங்கிலியின் max_block_bytes; தொகுப்பின் நான்கு உறைகள் ஒவ்வொன்றும், செயல் கொண்டுசெல்லும் எந்தக் குறிப்பு உறையும், சரியாக ஜெனிசிஸின் envelope_bytes (சங்கிலி 20-இல் 1,860; இந்தப் புலம் இல்லாத சங்கிலியில் அதிகபட்சம் 2,048 பைட்டுகள்); தொகுப்புச் சான்று, அங்கீகாரச் சான்று, ஓர் அழைப்புச் சான்று ஒவ்வொன்றும் ≤ max_proof_bytes (இயல்பாக 2 MiB, சங்கிலி 20-இன் ஜெனிசிஸில் 4 MiB; சங்கிலிகள் 13 முதல் 16 வரை இது 8 MiB ஆக இருந்தது); ஒரு நிரல் ≤ சங்கிலியின் நிரல் வரம்பு (இயல்பாக 4,096 சொற்கள், சங்கிலி 20-இன் ஜெனிசிஸில் 65,535); ஓர் அழைப்பு உறை ≤ max_call_envelope_bytes (இயல்பாக 18,432 பைட்டுகள், சங்கிலி 20-இல் 65,536); ஒரு சான்றளிப்பு ≤ 16 KiB. முத்திரையிடப்பட்ட (கத்தரிக்கப்பட்ட) குறிப்பான் வடிவிலுள்ள தொகுப்புச் சான்று, முத்திரை-வடிவ ஒத்திசைவுக்கு வெளியே, எந்தச் சான்றுப் பணிக்கும் முன்பே இங்கு மறுக்கப்படுகிறது (PrunedFormOutsideSync).
2. சங்கிலி அடையாளம் பொருந்துகிறது.
3. வடிவமும் கட்டணத் தளமும் — தொகுப்பு இல்லாத செயல் எந்தத் தொகுப்பையும் கொண்டிருப்பதில்லை; மற்ற ஒவ்வொன்றும் சரியாக ஒன்றைக் கொண்டிருக்க வேண்டும்; மூன்று எரிப்புப் புலங்களில் எவற்றைச் செயல் அமைக்கலாம் என்பதை check_burn_shape நிர்ணயிக்கிறது: ஒரு TokenBurn அல்லது BridgeBurn தன் சொந்த asset, amount ஆகியவற்றை burn_asset, burn_a வழியாக எரிக்கிறது; ஒரு Bond அல்லது RegisterAggregator தன் தொகையை burn_r வழியாக எரிக்கிறது; மற்ற ஒவ்வொரு செயலும் எதையும் எரிப்பதில்லை; fee ≥ fee_floor(action). gas பிரிவு கொண்ட சங்கிலியில் (சங்கிலி 20) இந்தப் படியில் ஒரு Call அல்லது Invoke-இன் தளம், அறிவிக்கப்பட்ட வரம்பு 1-இல் உள்ள கேஸ் விதியாகும்: அதன் சான்று மற்றும் உள்ளீட்டு உறையின் மீது BUNDLE_BASE + gas_price + byte_price × ⌈bytes / 1024⌉; இவை எந்தச் சரிபார்ப்புக்கும் முன்பே தெரிந்தவை.
4. நங்கூரம் — சங்கிலி 20-இல் கடைசி 1,024 பிளாக்-முடிவு வேர்களில் ஒன்று; அதன் ஜெனிசிஸ் proof_window_blocks: 1024 என அமைக்கிறது (v0.6.8); இந்தப் புலம் இல்லாத சங்கிலியில், சங்கிலி 19 வரை இருந்தது போல, கடைசி 256-இல் ஒன்று.
5. நேரம் — சங்கிலி 20-இல் [height − 1024, height] வரம்புக்குள்; புலம் இல்லாவிட்டால் [height − 256, height]. ஒரே ஜெனிசிஸ் மதிப்பு இரு சாளரங்களையும் அமைக்கிறது.
6. நல்லிஃபையர்களும் உறுதிமொழிகளும் — நான்கு நல்லிஃபையர்களும் ஒன்றுக்கொன்று வேறுபட்டவை, எதுவும் செலவிடப்படவில்லை; நான்கு உறுதிமொழிகளும் ஒன்றுக்கொன்று வேறுபட்டவை, எதுவும் ஏற்கெனவே ஓர் இலையாக இல்லை.
7. செயல் சோதனைகள் — ஃபாசெட் இயக்கப்பட்டுள்ளது; மின்ட் வரம்புக்குள் உள்ளது, சரிபார்ப்பாளரால் கையொப்பமிடப்பட்டுள்ளது; சங்கிலி 20-இல் அது ஜெனிசிஸ் staking.faucet_recipients அனுமதிப் பட்டியலிலுள்ள ஒரு பெறுநரைக் குறிப்பிடுகிறது, எபாக்கின் faucet_budget_per_epoch-க்குள் அடங்குகிறது, ஜெனிசிஸ் staking.faucet_minters பட்டியலிலுள்ள ஒரு சரிபார்ப்பாளரால் கையொப்பமிடப்பட்டுள்ளது (சங்கிலி 16 முதல் இது ஒரு செல்லுபடி விதி); 2⁶³ அல்லது அதற்கு மேற்பட்ட மின்ட் அல்லது வைப்பு ஒவ்வொரு சங்கிலியிலும் மறுக்கப்படுகிறது; நிரல் குறிவிலக்கப்படுகிறது; நிரல் இருக்கிறது; ஸ்டேக்கிங் விதிகள் (சரிபார்ப்பாளர் அறியப்படாதபோது மட்டுமே பதிவு இருத்தல், nonce, கையொப்பம், போதுமான ஸ்டேக்); BridgeAttest, BridgeBurn ஆகியவற்றுக்கும் இடைநிறுத்த, பட்டியலிடல் செயல்களுக்குமான பாலத்தின் சொந்த விதிகள்; பதிவுக் கட்டணம் உட்பட, RPL-இன் நான்கு செயல்களுக்கான அதன் விதிகள்; சங்கிலி 20-இல் அனுமதி வாக்கெடுப்பின் கோரம், மேலும் ஒரு Invoke-க்கு மாற்றத்தின் வடிவம், சேமிக்கப்பட்ட செல்களுக்கு எதிராக அறிவிக்கப்பட்ட வாசிப்புகள், ஒவ்வொரு செலுத்துகைக்குமான பெட்டகத்தின் ஈடு, செல் கட்டணம். இவை அனைத்தும் தொகுப்பின் சான்றுக்கு முன்பே இயங்குகின்றன; ஆகவே பயன்படுத்த முடியாத பரிவர்த்தனைக்கு STARK சரிபார்ப்புச் செலவு எதுவும் இல்லை. hardening_v6 கீழ் (சங்கிலிகள் 16 முதல் 20) இன்னும் இரண்டு மறுப்புகள் இங்கு உள்ளன: எந்த அழைப்பாலும் கொள்ள முடியாத நிரலின் Deploy (ProgramUncallable), நேர்மையான நிரூபிப்பவர் எழுதாத ஒரு புலத்தைத் தலைப்பிலோ டிரான்ஸ்கிரிப்டிலோ கொண்ட தொகுப்பு அல்லது அழைப்புச் சான்று (non-canonical proof: …); இவை இரண்டில் எந்தச் சான்றும் சரிபார்க்கப்படுவதற்கு முன்பே மறுக்கப்படுகின்றன. v0.6.8 முதல், மிக உயரமான அட்டவணையின் உச்சவரம்பைத் தாண்டிய படியைத் தலைப்பில் அறிவிக்கும் சான்று, சோதனை அதைக் கடந்து செல்வதற்கு முன்பே, அதே தீர்ப்பின் கீழ் முதலில் மறுக்கப்படுகிறது (தணிக்கை v6 ZKV-4).
8. தொகுப்பு டைஜஸ்ட் — பிரிக்கப்பட்ட அங்கீகாரச் சங்கிலியில் (சங்கிலி 17 முதல் ஒவ்வொரு சங்கிலியும்) அங்கீகாரப் புலங்கள் முதலில் சோதிக்கப்படுகின்றன: அங்கீகாரச் சான்று இல்லாத தொகுப்பு மறுக்கப்படுகிறது; அங்கீகாரச் சான்று வெளியிடும் c (வாசிக்கப்பட்டது, இன்னும் சரிபார்க்கப்படவில்லை) auth_commit-க்குச் சமமாக இருக்க வேண்டும்; சங்கிலி 20-இல் அங்கீகாரச் சான்று சரியாக 1,279 என்ற GAS_LIMIT-ஐ அறிவிக்க வேண்டும். பின்னர் பேரேடு, auth_commit உட்பட, தொகுப்பின் வெளியிடப்பட்ட புலங்களின் டைஜஸ்டை மீண்டும் கணக்கிடுகிறது; அது சான்று வெளியிட்டதற்குச் சமமாக இருக்க வேண்டும். சங்கிலி 20-இல் தொகுப்புச் சான்றும் சரியாக ஜெனிசிஸ் bundle_gas_limit ஆன 20,479 என்ற GAS_LIMIT-ஐ அறிவிக்க வேண்டும்.
9. தொகுப்புச் சான்று — ஜெனிசிஸில் நிலைநிறுத்தப்பட்ட hc_bundle-க்கும் பரிவர்த்தனையின் பிணைப்புக்கும் எதிராக Machine::verify_public. பிரிக்கப்பட்ட அங்கீகாரச் சங்கிலியில் அடுத்ததாக அங்கீகாரச் சான்று, ஜெனிசிஸில் நிலைநிறுத்தப்பட்ட hc_auth-க்கும் அதே பிணைப்புக்கும் எதிராகச் சரிபார்க்கப்படுகிறது.
10. அழைப்புச் சான்றும் அதன் அடுக்குக் கட்டணமும் — ஒரு Call அல்லது Invoke-க்கு, முதலில் சான்றின் தலைப்பு நிலைநிறுத்தப்படுகிறது (அடுக்கு அதிகபட்சம் 14, keccak அட்டவணை அதிகபட்சம் 2¹², sha256 அட்டவணை அதிகபட்சம் 2¹³, hardening_v6 கீழ் குறைந்தபட்சம் 2⁷ வரிசைகள் எனத் தளமிடப்பட்ட, நிறுவப்பட்ட நிரலின் உயரம், மேலும் சங்கிலி 20-இல் தலைப்பின் உச்சவரம்பு gas_max-ஐ விட அதிகமில்லாத அறிவிக்கப்பட்ட GAS_LIMIT); பின்னர் நிரலின் code_hash-க்கும், hardening_v6 கீழ் பரிவர்த்தனையின் அழைப்புப் பிணைப்புக்கும் எதிராக அழைப்பின் STARK. கட்டணம் கடைசியாகச் சோதிக்கப்படுகிறது, ஏனெனில் சான்று குறிவிலக்கப்பட்ட பின்னரே அதை அறிய முடியும்: சங்கிலி 20-இல் நடைமுறையிலுள்ள விலைகளில் fee ≥ BUNDLE_BASE + gas_price × GAS_LIMIT + byte_price × ⌈bytes / 1024⌉, மேலும் ஒரு Invoke-க்கு உருவாக்கப்படும் ஒவ்வொரு செல்லுக்கும் cell_fee (கட்டணங்கள்); gas பிரிவு இல்லாத சங்கிலியில் fee ≥ BUNDLE_BASE + call_fee(tier).

பிழைகள் rand_sendTransaction-இலிருந்து -32000 குறியீட்டுடனும் காரணத்துடனும் திரும்புகின்றன: nullifier already spent, anchor is not one of the last 1024 roots (proof_window_blocks இல்லாத சங்கிலியில் 256), time 12 is outside [476, 1500], fee 1000000 below minimum 2000000, the bundle's digest is not what its proof published, invalid bundle proof: …, unknown program …, already in mempool, conflicts with a pending transaction over <nullifier>, faucet is disabled on this chain, சங்கிலி 14 முதல் the bundle burns asset 2 on an action that burns no token, a burn of 5 is not allowed on this action, the bundle burns 399, not the 400 the action declares, wrong mint nonce: expected 1, got 0, wrong token index: expected 3, got 2, சங்கிலி 17 முதல் this chain requires an auth proof on every bundle (genesis hc_auth), the auth proof publishes a different commitment than the bundle's auth_commit, மேலும் சங்கிலி 20-இல் envelope is 1348 bytes, this chain requires exactly 1860, bundle proof declares gas limit …, this chain requires exactly 20479. ஏற்றுக்கொள்ளப்படுதல் என்பது உறுதிசெய்யப்படுதல் அல்ல: rand_getTransaction ஒரு பிளாக்கைத் திருப்பும் வரை அதை வினவிக்கொண்டிருங்கள்.

செல்லாத பரிவர்த்தனை ஏதேனும் கொண்ட பிளாக் செல்லாதது. மெம்பூல் நிலுவையிலுள்ள ஒவ்வொரு நல்லிஃபையரையும் உறுதிமொழியையும் அட்டவணைப்படுத்தி, முரண்பாட்டை நேரடியாக மறுக்கிறது; ஆகவே ஒரே குறிப்பைச் செலவிடும் இரு தொகுப்புகள் ஒருபோதும் ஒரே பிளாக்கில் இடம்பெறுவதில்லை.

அளவுகள்

முதல் ஆறு வரிசைகள் சங்கிலி 18 முதலான குறியாக்கத்தைக் காட்டுகின்றன: மெமோ புலம் ஒவ்வொரு உறைக்கும் 512 பைட்டுகளைச் சேர்த்தது; பிரிக்கப்பட்ட அங்கீகாரம், அங்கீகாரச் சான்றின் சொந்தப் பைட்டுகளுக்கு முன்பே, தொகுப்புக்கு 40 பைட்டுகளைச் சேர்த்தது. ஆகவே சங்கிலி 18 முதல், சங்கிலி 20 உட்பட, இணைப்பில் ஒரு மறைக்கப்பட்ட பரிமாற்றம் சுமார் 2.88 MB; அது எந்தச் சொத்தை நகர்த்தினாலும் கிட்டத்தட்ட முழுவதும் சான்றே: சுமார் 1.5 MB தொகுப்புச் சான்று, 1.37 MB அங்கீகாரச் சான்று. சங்கிலி 15 வரை, ஒரே சான்றுடன், அது சுமார் 1.43 MB ஆக இருந்தது. பிளாக்குகள் 2,000 பரிவர்த்தனைகள் (MAX_BLOCK_TXS) எனவும், சங்கிலியின் max_block_bytes அளவு பரிவர்த்தனைப் பைட்டுகள் எனவும் வரம்பிடப்பட்டுள்ளன; இரண்டும் ஒருமித்த ஒப்புதல் விதிகள்: இயல்பாக 4 MiB (MAX_BLOCK_BYTES), இது அத்தகைய ஒரு பரிமாற்றத்தை மட்டுமே கொள்ளும்; சங்கிலி 20-இன் ஜெனிசிஸில் 20 MiB, இதில் ஏழுக்கு இடம் உண்டு. hc_auth கொண்ட ஜெனிசிஸ் max_block_bytes-ஐக் குறைந்தது max_proof_bytes-இன் மூன்று மடங்குடன் 1 MiB சேர்த்த அளவாக அமைக்க வேண்டும், ஏனெனில் ஒரு பரிவர்த்தனை மூன்று சான்றுகளைக் (தொகுப்பு, அங்கீகாரம், அழைப்பு) கொண்டிருக்கலாம்; ஆகவே அங்கு 4 MiB இயல்புநிலை மறுக்கப்படுகிறது. பிளாக்-நிலைத் திரட்டலே வரிசையில் காத்திருக்கும் தீர்வு; சான்றுகள் பார்க்கவும்.

ஒன்றைத் திரும்ப வாசித்தல்

rand_getTransaction(hash) பரிவர்த்தனை உறுதிசெய்யப்படும் வரை null-ஐத் திருப்புகிறது; பின்னர் அதன் பிளாக் நிலையையும் பொதுப் புலங்களை மட்டும்மே திருப்புகிறது:

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

ஒரு பரிமாற்றத்தில் from, to, nonce, தொகை, asset புலம் எதுவும் இல்லை; சேமிக்கப்பட்ட பிளாக்கிலும் இவை எதுவும் இல்லை: node மறைப்பதற்கு வேறெதுவும் இல்லை. chain 17 முதல் auth_commit, auth_proof_bytes (auth நிரூபணத்தின் நீளம்) ஆகியவை இடம்பெறுகின்றன. bundle-இல் எப்போதும் நான்கு இடங்கள் இருக்கும், போலி இடங்களும் உட்பட; RAND பரிமாற்றமும் எந்த RPL டோக்கனின் பரிமாற்றமும் "kind": "none" ஆகவே தோன்றும். chain 14 முதல் ஒவ்வொரு u64 தொகையும் தசம எண் சரமாக உள்ளது (fee, burn_a, burn_r, ஒரு செயலின் amount); குறியீட்டெண்கள், nonce-கள், உயரங்கள், நீளங்கள் JSON எண்களாகவே இருக்கும். பிற செயல் வகைகள் தங்கள் பொதுப் புலங்களைக் காட்டுகின்றன: mint, deploy, call, bond, unbond, withdraw, bridge_attest, bridge_burn, register_token, token_mint, set_authority, token_burn, pause_mints, unpause_mints, register_bridged_token, list_backing, rotate_pq_guardians, rotate_pause_key, நான்கு vesting வகைகளான claim_vested, revoke_vesting, bond_vested, unbond_vested, மேலும் v0.6.8 முதல் admit_validator, slash_equivocation, rotate_pq_guardians_v2, rotate_pause_key_v2, cancel_rotation, invoke. இவை JSON-RPC குறிப்பேட்டில் பட்டியலிடப்பட்டுள்ளன.