راکړې ورکړې او کړنې

دا پاڼه د یوې راکړې ورکړې د جوړولو، سپارلو یا کوډ‌ماتولو لپاره وکاروئ: هغه wire بڼه چې 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 اته little-endian u32 کلمې دي چې د 64 کوچنیو hex تورو په بڼه ښودل کېږي. wire بڼه bincode(Transaction) ده چې د bincode له اصلي تنظیماتو سره (ثابت‌پلن عددونه، 8-بایټي اوږدوالي مختاړي، u32 enum ټګونه) جوړېږي، او rand_sendTransaction یې د hex په بڼه اخلي. پر راکړه ورکړه هېڅ لاسلیک نشته او د لېږونکي هېڅ ساحه نشته: یو بنډل خپل ځان د خپلو ثبوتونو له لارې اجازه ورکوي (د بنډل ثبوت او، له chain 17 راهیسې، د هغه تر څنګ د auth ثبوت)، او هغه کړنه چې لاسلیک لري، لاسلیک په خپل ځان کې لېږدوي. د بیا‌لېږلو پر وړاندې ساتنه د بنډلونو لپاره د باطلوونکو ټولګه ده، د لاسلیک‌شوو staking کړنو لپاره په راجسټر کې د هر تاییدوونکي nonce، د TokenMint او SetAuthority لپاره د هر ټوکن mint_nonce، او د bridge د حاکمیتي کړنو لپاره د هغه pause_nonce او list_nonce.

یوه راکړه ورکړه تر ټولو ډېر یو بنډل لېږدوي، او هره هغه کړنه چې بې‌بنډله نه وي، دقیقاً یو بنډل لري. د بنډل 0–1 ځایونه یوه خصوصي شتمني لېږدوي او 2–3 ځایونه RAND، نو یو ثبوت یو ټوکن لېږدوي او د هغه RAND فیس ورکوي؛ د پخواني ډیزاین دوه‌بنډله bridge burn له منځه تللې ده: یو burn یو بنډل دی (یادښتونه).

د rand والټ دا ټول د randprotocol_client::wallet::{send, submit} له لارې جوړوي: ننوتې ټاکي، anchor راوړي، شاهدان د والټ د ونې له خپلې کاپي څخه محاسبه کوي، وتنې جوړوي او ټولې څلور لفافې مهروي، د راکړې ورکړې تړنه اخلي، بنډل او auth ثبوت ثابتوي، د بنډل د ثبوت خپور شوی digest کتل کوي، او سپارل یې کوي.

د راکړې ورکړې تړنه

یوه راکړه ورکړه لاسلیک نه لري، او د بنډل ثبوت یوازې د بنډل خپل digest ته ژمنه کوي: anchor، باطلوونکي، ژمنې، فیس، د burn ساحې، 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، ټولې څلور لفافې، د burn هره ساحه، منزل، تاییدوونکی، ترلاسه‌کوونکی، لاسلیکونه، د ساتونکي تصدیق او د هغه Dilithium2 ګډ لاسلیکونه، او د Call خپل ثبوت. دا اته کلمې د ثبوت د عامه ننوتې په برخه کې ځي، چې digest یې H_PUB سرکټ دمخه تړلی دی، نو دې سمون د guest یا سرکټ هېڅ بدلون ته اړتیا نه درلوده؛ نوډ Machine::verify_public(hc_bundle, binding, proof) چلوي او د بنډل هغه ثبوت ردوي چې بله کومه عامه لوړوالی اعلانوي (public height not the transaction binding's). Transaction::binding هغه یوازینی فنکشن دی چې والټ یې له ثابتولو مخکې او لېجر یې له تاییدولو مخکې بلي. له chain 17 راهیسې auth ثبوت هم د همدې اتو کلمو پر بنسټ جوړېږي او د هغو پر وړاندې تاییدېږي، نو هغه هم بلې راکړې ورکړې ته نشي لېږدول کېدای.

Chain 20 د genesis hash تړي. تر chain 19 پورې تړنې، او د بې‌بنډله کړنو لاسلیک‌شوو پیغامونو، یوازې chain id پوښلو، نو دوه chains چې یو chain id یې شریک وای (بیا‌پرې‌کول، یوه خصوصي کاپي) د یو بل ثبوتونه او لاسلیکونه به یې منلي وای. د Chain 20 genesis binding_domain: 1 ټاکي (v0.6.8، audit v6 BIND-1؛ crates/randprotocol-core/src/types/binding.rs). بیا genesis hash د هر preimage په سر کې د یوې نسخې لوړ ټګ لاندې راځي: د دوو تړنو لپاره rand-tx-bind-2 او rand-call-bind-2، او همداسې د faucet mint (rand-mint-3)، Unbond او Withdraw (rand-unbond-2، rand-withdraw-2)، د RPL د mint او واک پیغامونو (rand-rpl-mint-2، rand-rpl-authority-2)، د راټولوونکي کړنو او د bridge د حاکمیتي پیغامونو لپاره. پر داسې chain د تاییدوونکي نوم‌لیکنه تل v2 پیغام دی (genesis، chain، پته، payout). هېڅ شی چې د یوه chain لپاره ثابت یا لاسلیک شوی وي، پر بل chain نه تاییدېږي، که هر chain id یې وي. د تړنې کلمې عامه ننوته ده، نو د guest یا تاییدوونکي هېڅ کیلي بدله نه شوه. له v0.6.8 څخه زوړ والټ لا هم د chain id پر بڼه ثابتوي او پر chain 20 ردېږي. rand_getLimits او rand_status binding_domain وړاندې کوي (پر chain 20 1، او له دې ساحې پرته 0).

د genesis hardening_v6 لاندې (chains 16 تر 20) د Call خپل ثبوت هم تړل کېږي، د همدې جوړښت د دوهم digest له لارې چې خپله ډومېن لري، او پکې د بنډل د ثبوتونو ترڅنګ د 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 دی او genesis hash د preimage په سر کې راځي، لکه څنګه چې پورته وویل شول. د Invoke ثبوت هم همداسې تړل کېږي، او اعلان شوی لېږد یې په preimage کې ساتل کېږي، نو ثبوت دقیقاً هغه حالت بدلون، تادیاتو او ترلاسه‌کوونکو ته ژمنه کوي چې راکړه ورکړه یې لېږدوي.

د call ثبوت دا کلمې د خپلې عامه ننوتې په برخه کې لېږدوي، د پروګرام د deploy-time عامه ننوتې وروسته کله چې ولري یې، نو د هغه یوه کاپي چې له بل فیس بنډل سره نښلول شوې وي نه تاییدېږي. دواړه تړنې یو په بل کې ځای لري: والټ د فیس بنډل یادښتونه ټاکي او راکړه ورکړه له خالي ثبوتونو سره جوړوي، call د call تړنې پر وړاندې ثابتوي، دا ثبوت دننه ږدي، او یوازې بیا د راکړې ورکړې تړنه اخلي او بنډل ثابتوي.

د پېرودونکي سافټویر لپاره پایله: ټوله راکړه ورکړه — وتنې، لفافې، کړنه — له ثابتولو مخکې جوړه کړئ. هغه والټ چې له fork مخکې جوړ شوی وي، د خالي عامه برخې پر وړاندې ثابتوي او ردېږي. بې‌بنډله کړنې د تړلو لپاره ثبوت نه لري او پر خپلو لاسلیکونو تکیه کوي. تړنه د راکړې ورکړې پېژند نه ده، چې نه دی بدل شوی.

د راکړې ورکړې پېژند

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

چېرته چې view هغه راکړه ورکړه ده چې پکې د بنډل د proof بایټونه په blake3(proof) (proof_hash) او د هغه د auth_proof بایټونه په blake3(auth_proof) (auth_proof_hash، د auth_commit وروسته، چې هماغسې ننوځي) بدل شوي، او نورې ټولې ساحې په ټکي‌په‌ټکي ډول. ډومېن تر chain 16 پورې rand-txid-2 و، له دوو auth ساحو پرته؛ له chain 17 سره د راکړې ورکړې هر پېژند بدل شو. د ثبوت hash د هغه د digest له لارې دا امکان ورکوي چې یو پرې‌شوی بنډل (د بلاک راټولونه، چې پر chain 20 فعاله نه ده) د خپلې خامې بڼې هماغه پېژند وساتي؛ پرې‌شوی بنډل خپل auth ثبوت ساتي. بې‌بنډله راکړه ورکړه خپل بایټونه هماغسې hash کوي. همدا پېژند د mempool، رسیدونو او هرې 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 د کارولو وړ دي. د دې پیدایښت یوه bridge برخه د rules_v2 سره، یوه 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 د کارولو وړ وو (زنځیر 14، د rules_v2 پرته، 22 او 23 ردول). SlashEquivocation یوې staking.slashing برخې ته اړتیا لري، او د زنځیر 20 دا برخه null ده. د راټولولو پنځه عملونه یوې aggregation برخې ته اړتیا لري، چې زنځیر 20 یې نه لري (یوه جوړونه پر داسې پیدایښت له پیلېدو ډډه کوي چې دا برخه ولري، تر هغه چې راټولول بیا اندازه شي). یو نوډ دا ټول له هر بل چک مخکې پر دروازه ردوي، خو دوی لا هم خپل bincode ټګونه نیسي، نو هغه کوډوونکی چې د ټګونو شمېرې په کلکه لیکي باید دوی هم وشمېري. راټولول په ثبوتونه کې د راتلونکې ځانګړنې په توګه مستند شوي. د پیدایښت د وېستینګ څلور عملونه (ټګونه 24 تر 27، چې له v0.5.11 راهیسې په جوړونه کې دي) یوې vesting برخې ته اړتیا لري، چې هېڅ زنځیر، زنځیر 20 په ګډون، نه ده لرلې، او له دې پرته د منلو پر مهال ردېږي. ټګونه 28 تر 33 په v0.6.8 کې نوي دي او په پای کې ورزیات شوي، نو د هر پخواني زنځیر تاریخ لا هم ډیکوډ کېږي.

د RPL څلور عملونه (ټګونه 14 تر 17) یو ټوکن راجستر کوي، د Key لخوا واکمن شوي ټوکن نور مقدار جوړوي، د هغه د جوړولو واک سپاري یا پرېږدي، او یوه شتمني سوځوي؛ هغه RegisterToken چې د Bridge یا Program واک نوموي ردېږي. د ټوکن د لېږد کوم ځانګړی عمل نشته: د ټوکن لېږد None دی، چې له RAND تادیې څخه نه توپیرېږي. RPL ټوکنونه وګورئ. د پل د حکومتولۍ څلور عملونه (ټګونه 18 تر 21) د جوړولو ځنډول، د هغه لرې کول، او له پیدایښت وروسته د یوه پل شوي ټوکن یا د یوه بل ملاتړ لیست کول دي. PauseMints د پیدایښت د ځنډولو کیلي لخوا لاسلیک کېږي، چې یوازې ځنډولی شي؛ نور درې د Dilithium2 (PQ) ساتونکو یوې کوروم ته اړتیا لري. یو BridgeAttest هم، د خپل ECDSA کوروم تر څنګ، داسې یوه کوروم لري. ټګونه 22 او 23، د پل د rules_v2 لاندې، د 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_a له لارې، په داسې حال کې چې burn_asset هغه نوموي، په یوه TokenBurn، یوه BridgeBurn یا یوه Invoke کې. نور هر عمل هېڅ نه سوځوي، او هغه بنډل چې burn_asset = 0 او burn_a غیر صفر ولري هر ځای ردېږي.

د منلو ترتیب

Ledger::validate_inner ارزانه شیان له ګرانو مخکې، په دې ترتیب، چکوي؛ میمپول هم له خپرولو مخکې همدا چک چلوي، نو یوه ناسمه معامله یو ځل، په څنډه کې، ردېږي.

1. د اندازې پولې — ټوله راکړه ورکړه ≤ د زنځیر max_block_bytes؛ د بنډل له څلورو لفافو هره یوه، او هره د نوټ لفافه چې عمل یې له ځانه سره لري، دقیقاً د جینیسس envelope_bytes (په chain 20 کې 1,860؛ په هغه زنځیر کې چې دا ساحه نه لري تر ډېره 2,048 بایټه)؛ د بنډل ثبوت، د auth ثبوت او د call ثبوت هر یو ≤ max_proof_bytes (په ډیفالټ ډول 2 MiB، د chain 20 په جینیسس کې 4 MiB؛ له chain 13 تر 16 پورې 8 MiB و)؛ پروګرام ≤ د زنځیر د پروګرام پوله (په ډیفالټ ډول 4,096 کلمې، د chain 20 په جینیسس کې 65,535)؛ د call لفافه ≤ max_call_envelope_bytes (په ډیفالټ ډول 18,432 بایټه، په chain 20 کې 65,536)؛ تصدیق‌نامه ≤ 16 KiB. د بنډل هغه ثبوت چې په مهر شوې (pruned) نښه‌يي بڼه وي، له مهر شوې بڼې د همغږۍ پرته دلته ردېږي (PrunedFormOutsideSync)، مخکې له دې چې د ثبوت کوم کار وشي.
2. Chain id سمون لري.
3. بڼه او د فیس ټیټه پوله — هغه عمل چې بنډل نه لري هېڅ بنډل له ځانه سره نه لري، او هر بل عمل باید دقیقاً یو بنډل ولري؛ check_burn_shape ټاکي چې عمل د سوځولو له دریو ساحو کومې ټاکلی شي: TokenBurn یا BridgeBurn خپل asset او amount د burn_asset او burn_a له لارې سوځوي، Bond یا RegisterAggregator خپله اندازه د burn_r له لارې سوځوي، او هر بل عمل هېڅ نه سوځوي؛ fee ≥ fee_floor(action). په هغه زنځیر کې چې gas برخه لري (chain 20)، په دې پړاو کې د Call یا Invoke ټیټه پوله د 1 په اعلان شوې حد کې د ګاز قاعده ده، BUNDLE_BASE + gas_price + byte_price × ⌈bytes / 1024⌉ د هغه د ثبوت او د ننوتو د لفافې پر سر، چې دواړه له هر ډول تایید مخکې معلوم دي.
4. لنګر — په chain 20 کې د بلاک پای د وروستیو 1,024 ریښو له منځه یوه، چې جینیسس یې proof_window_blocks: 1024 ټاکي (v0.6.8)؛ په هغه زنځیر کې چې دا ساحه نه لري د وروستیو 256 له منځه یوه، لکه تر chain 19 پورې.
5. وخت — په chain 20 کې د [height − 1024, height] دننه؛ له دې ساحې پرته [height − 256, height]. د جینیسس یو ارزښت دواړه کړکۍ ټاکي.
6. Nullifiers او ژمنې — ټول څلور nullifiers سره توپیر لري او هېڅ یو نه دی لګول شوی؛ ټولې څلور ژمنې سره توپیر لري او هېڅ یوه لا دمخه پاڼه نه ده.
7. د عمل ازموینې — faucet فعال دی، mint له پولې لاندې او د validator لخوا لاسلیک شوی دی، او په chain 20 کې داسې ترلاسه کوونکی نوموي چې د جینیسس د staking.faucet_recipients د اجازې په لیست کې وي، د epoch په faucet_budget_per_epoch کې ځاییږي او د هغه validator لخوا لاسلیک شوی وي چې د جینیسس د staking.faucet_minters په لیست کې وي (له chain 16 راهیسې د اعتبار قاعده)؛ هغه mint یا زیرمه چې 2⁶³ یا له هغې زیاته وي په هر زنځیر کې ردېږي؛ پروګرام ډیکوډ کېږي؛ پروګرام شتون لري؛ د staking قواعد (ثبت نوم یوازې هغه وخت شته چې validator نامعلوم وي، nonce، لاسلیک، کافي ونډه)؛ د BridgeAttest او BridgeBurn او د درولو او لیست کولو د عملونو لپاره د bridge خپل قواعد؛ د RPL د څلورو عملونو قواعد، د ثبت نوم د فیس په ګډون؛ په chain 20 کې د منلو د رایې نصاب، او د Invoke لپاره د لېږد بڼه، اعلان شوې لوستنې د زېرمه شویو cells په وړاندې، د هرې تادیې لپاره د vault پوښښ او د cell فیس. دا ټول د بنډل له ثبوت مخکې ترسره کېږي، نو هغه راکړه ورکړه چې پلي کېدای نه شي د STARK هېڅ تایید نه لګوي. د hardening_v6 لاندې (له chain 16 تر 20 پورې) دوه نور ردونه دلته دي: د داسې پروګرام Deploy چې هېڅ call یې نه شي ساتلی (ProgramUncallable)، او د بنډل یا call هغه ثبوت چې سرلیک یا transcript یې داسې ساحه ولري چې صادق prover به یې نه لیکي (non-canonical proof: …)، چې د کوم یو ثبوت له تایید مخکې ردېږي. له v0.6.8 راهیسې هغه ثبوت چې سرلیک یې د تر ټولو لوړ جدول له سقف هاخوا درجه اعلانوي، د همدې پرېکړې لاندې لومړی ردېږي (audit v6 ZKV-4)، مخکې له دې چې ازموینه پرې تېره شي.
8. د بنډل digest — په هغه زنځیر کې چې واک پکې وېشل شوی (له 17 راهیسې هر زنځیر) لومړی د auth ساحې ازمول کېږي: هغه بنډل چې auth ثبوت نه لري ردېږي، هغه c چې auth ثبوت یې خپروي (لوستل شوی، خو لا نه دی تایید شوی) باید له auth_commit سره برابر وي، او په chain 20 کې auth ثبوت باید دقیقاً د 1,279 GAS_LIMIT اعلان کړي. بیا لیجر د بنډل د خپرو شویو ساحو digest بیا محاسبه کوي، چې auth_commit هم پکې شامل دی، او دا باید له هغه څه سره برابر وي چې ثبوت خپور کړی. په chain 20 کې د بنډل ثبوت هم باید دقیقاً د جینیسس bundle_gas_limit، یعنې 20,479، GAS_LIMIT اعلان کړي.
9. د بنډل ثبوت — Machine::verify_public د جینیسس لخوا ټاکل شوي hc_bundle او د راکړې ورکړې د binding په وړاندې. په هغه زنځیر کې چې واک پکې وېشل شوی، وروسته auth ثبوت د جینیسس لخوا ټاکل شوي hc_auth او همدې binding په وړاندې تاییدېږي.
10. د call ثبوت او د هغه د tier فیس — د Call یا Invoke لپاره، لومړی د ثبوت سرلیک ټاکل کېږي (tier تر ډېره 14، د keccak جدول تر ډېره 2¹²، د sha256 جدول تر ډېره 2¹³، د ځای پر ځای شوي پروګرام لوړوالی چې د hardening_v6 لاندې یې ټیټه پوله 2⁷ قطارونه دي، او په chain 20 کې اعلان شوی GAS_LIMIT چې د سرلیک له سقف gas_max څخه زیات نه وي)، بیا د call STARK د پروګرام د code_hash او، د hardening_v6 لاندې، د راکړې ورکړې د call binding په وړاندې. فیس په پای کې ازمول کېږي، ځکه چې یوازې د ثبوت له ډیکوډ کېدو وروسته معلومېدای شي: په chain 20 کې fee ≥ BUNDLE_BASE + gas_price × GAS_LIMIT + byte_price × ⌈bytes / 1024⌉ په نافذو بیو، او د Invoke لپاره د هر جوړ شوي cell لپاره 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، او له 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، له chain 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، او په chain 20 کې envelope is 1348 bytes, this chain requires exactly 1860 او bundle proof declares gas limit …, this chain requires exactly 20479. منل کېدل د ثبت معنا نه لري: rand_getTransaction تر هغه وخته پوښتئ چې بلاک بېرته راکړي.

هغه بلاک چې هره ناسمه راکړه ورکړه ولري ناسم دی. mempool هر په تمه nullifier او ژمنه انډکس کوي او ټکر په بشپړه توګه ردوي، نو هغه دوه بنډلونه چې ورته نوټ لګوي هېڅکله په یوه بلاک کې نه راځي.

اندازې

لومړي شپږ قطارونه له chain 18 راهیسې کوډ کول دي: د memo ساحې هرې لفافې ته 512 بایټه ورزیات کړل، او د واک وېش د auth ثبوت له خپلو بایټونو مخکې بنډل ته 40 بایټه ورزیات کړل. نو له chain 18 راهیسې، د chain 20 په ګډون، په شبکه کې یو پټ شوی لېږد شاوخوا 2.88 MB دی، چې نږدې ټول یې ثبوت دی، هره شتمني چې لېږدوي: شاوخوا 1.5 MB د بنډل ثبوت او 1.37 MB د auth ثبوت. تر chain 15 پورې، له یوه ثبوت سره، شاوخوا 1.43 MB و. بلاکونه په 2,000 راکړو ورکړو (MAX_BLOCK_TXS) او د راکړې ورکړې د بایټونو په max_block_bytes د زنځیر پوله لري، چې دواړه د اجماع قواعد دي: په ډیفالټ ډول 4 MiB (MAX_BLOCK_BYTES)، چې یو داسې لېږد پکې ځاییږي، او د chain 20 په جینیسس کې 20 MiB، چې د اوو لپاره ځای لري. هغه جینیسس چې hc_auth لري باید max_block_bytes لږ تر لږه د max_proof_bytes درې چنده جمع 1 MiB وټاکي، ځکه چې یوه راکړه ورکړه درې ثبوتونه (بنډل، auth، call) لېږدولی شي، نو هلته د 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 ساحه نشته، او په زېرمه شوي بلاک کې هم هېڅ نشته: نوډ نور څه نه لري چې پټ یې کړي. auth_commit او auth_proof_bytes (د auth ثبوت اوږدوالی) له chain 17 راهیسې شته. بنډل تل څلور سلاټونه لري، جعلي سلاټونه هم پکې شامل دي، او د RAND لېږد او د هر RPL ټوکن لېږد دواړه "kind": "none" دي. له chain 14 راهیسې هر u64 مقدار یو لسیز string دی (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 مرجع کې لیست شوي.