فیسونه

دا پاڼه وکاروئ ترڅو د یوې راکړې ورکړې فیس وټاکئ، د یو deploy یا یوې غوښتنې لګښت اټکل کړئ، او پوه شئ چې validator ته څومره ورکول کېږي. فیسونه په RAND کې لږترلږه حدونه دي. له غوښتنې پرته هر عمل یو ثابت فیس ورکوي. په chain 20 کې یوه غوښتنه د هغه ګاز حد چې د هغې ثبوت یې اعلانوي او د خپلو بایټونو بیه ورکوي، په داسې بیو چې د بلاکونو د ډکوالي سره بدلېږي او په یوه پورتني حد کې دربېږي.

لږترلږه حدونه

فیسونه د 10⁻⁹ RAND په واحدونو کې دي. ثابت ارزښتونه په randprotocol_core::gas کې دي:

فیس د بنډل یوه عامه کلمه ده او تل RAND وي. د پټې شتمنۍ بنډل guest یې د RAND ډلې د بیلانس په اړیکه کې تړي، in₂ + in₃ = out₂ + out₃ + fee + burn_r (slots 2–3)، نو له پټو نوټونو څخه ورکول کېږي پرته له دې چې څرګنده شي له کومو؛ یو ټوکن د هماغه بنډل له slots 0–1 څخه د خپلې اړیکې لاندې تېرېږي، in₀ + in₁ = out₀ + out₁ + burn_a. نو یو ثبوت یو ټوکن لېږدوي او د هغه RAND فیس ورکوي، او هغه wallet چې ټوکن لري خو د لګولو وړ RAND نلري، له ثبوت جوړولو مخکې رد کېږي.

د bridge لګښت پر burn لوېږي ځکه چې دا یوازینۍ د bridge راکړه ورکړه ده چې لېږونکی یې یقیناً RAND لري؛ یوه زېرمه یوازې اساس ورکوي، ځکه چې زېرمه کوونکی لا RAND نلري. د راجسټریشن فیس د دفتر یو واقعیت دی، نه د fee_floor برخه، نو د عمل د خپلو قواعدو سره چک کېږي (RegistrationFeeTooLow)، لکه څنګه چې د غوښتنې د ګاز یا پوړ برخه هغه وخت اخیستل کېږي چې ثبوت یې decode شي. د غوښتنې لږترلږه حد دوه ځله چک کېږي، ځکه چې څه چې اعلانوي یوازې هغه وخت باوري دي چې ثبوت یې تصدیق شوی وي. په chain 20 کې لومړی چک، له هر تصدیق مخکې، د غوښتنې بایټونه او د 1 اعلان شوی حد بیه کوي (یو Invoke هلته خپل د حجرې فیس هم پوروړی دی)؛ دوهم هغه حد بیه کوي چې تصدیق شوی ثبوت یې اعلانوي. په هغه chain کې چې gas برخه نلري، دا دوه BUNDLE_BASE + CALL_BASE او د پوړ دقیق لږترلږه حد دي.

له اټکل پر ځای له node څخه وپوښتئ:

rand fee bundle          # 0.001 RAND
rand fee deploy 256      # 0.0266 RAND
rand fee call 14 --gas 20479 --bytes 1350000   # 0.0041 RAND at chain 20's starting prices

→ {"method":"rand_estimateFee","params":[{"kind":"call","tier":14,"gas":20479,"bytes":1350000}]}
← "4103100"

هغه ځواب د پیل په بیو کې 1,000,000 + 100 × 20,479 + 800 × 1,319 دی؛ node هغه بیې کاروي چې د پوښتنې په وخت کې د tip بیې وي. په chain 20 کې د غوښتنې د مشخصاتو gas ساحه په JSON-RPC کې اړینه ده (پرته له هغې -32602). rand fee call <tier> پرته له --gas څخه د پوړ پورتنی حد لېږي، او پرته له --bytes څخه هېڅ بایټ نه بیه کوي. یو invoke په هماغه ډول بیه کېږي، له "kind":"invoke" سره، او "created_cells": c د c حجرو فیسونه زیاتوي (د پورتني مثال لپاره له دوو حجرو سره 24103100، چې په 2026-10-01 له chain 20 څخه پوښتل شوی). په chain 15 کې، چې gas برخه یې نه درلوده، rand fee call 14 0.0022 RAND ځواب ورکړ.

د wallet تلوالې دقیقاً لږترلږه حدونه دي، پرته له chain 20 کې د یوې غوښتنې، چې تلواله یې اضافي ځای زیاتوي (لاندې)؛ rand send --fee <RAND> او د bond، call، bridge-mint، bridge-burn (تلواله 0.01) او د token فرعي کمانډونو --fee بیرغ یې لوړوي. له لږترلږه حد څخه پورته هر څه tip دی.

په chain 18 کې ګاز

chain 18، چې له 2026-09-29 څخه تر 2026-10-01 پورې ژوندی و، لومړنی د ګاز په اندازه کولو chain و، او chain 19، چې په هماغه build یې بیا genesis و، هماغه gas برخه درلوده. chain 20 (v0.6.8) د دې برخې هر قاعده ساتي او دوه د بیې پورتني حدونه او د بایټ یو بار زیاتوي چې یوازې په هغو بایټونو شمېرل کېږي چې ورکړه کوي (لاندې). هغه chain چې gas برخه نلري، په پورتني جدول کې د پوړونو مهالوېش ساتي.

څه شمېرل کېږي. یو ګاز د zkVM د cpu جدول یو قطار دی، نو یوه عادي لارښوونه 1 لګښت لري. syscalls یوازیني نور لګښتونه دي:

اعلان شوی حد. د غوښتنې ثبوت تر پخوا یو عام ارزښت ډېر لېږدوي، GAS_LIMIT، او سرکټ (constraint set 8) ثابتوي چې د اجرا ګاز له هغه سره برابر یا لږ دی. دقیق ګاز پټ پاتې کېږي. هغه حد چې د ثبوت د خپل header له پورتني حد څخه لوړ وي، مخکې له دې چې د verifier کیلي جوړه شي، رد کېږي:

gas_max = (2ᵗ − 1) + 2^(t−2) + 191 × (keccak rows / 32) + 63 × (sha256 rows / 64)

دا د هغې غوښتنې لپاره چې هېڅ hash جدول نه کاروي، په 10 پوړ کې 1,279، په 12 پوړ کې 5,119 او په 14 پوړ کې 20,479 دی.

لږترلږه حد. دفتر اعلان شوی حد او بایټونه د هغو بیو سره اخلي چې د بلاک د پیل پر وخت نافذې وي:

fee ≥ BUNDLE_BASE + gas_price × gas_limit + byte_price × ⌈bytes / 1024⌉

bytes د غوښتنې ثبوت جمع ورودي پوښ دی. د پوړونو مهالوېش او د هغه وړیا اجازه په داسې chain کې نه پلي کېږي. pool دقیقاً هغه غوښتنه کوي چې یو بلاک یې کوي، او ارزانه غوښتنه د FeeTooLow په توګه ردوي.

بنډلونه او د اجازې ثبوت ټاکلي حدونه اعلانوي. د هر بنډل ثبوت باید دقیقاً د genesis bundle_gas_limit، 20,479 (د 14 پوړ پورتنی حد)، اعلان کړي، کنه راکړه ورکړه د BundleGasLimit په توګه رد کېږي. chain 20، لکه له 17 راهیسې هر chain، وېشل شوې اجازه چلوي، نو هر بنډل د 10 پوړ د اجازې ثبوت لېږدوي، چې باید 1,279 اعلان کړي (AuthGasLimit). هېڅ یو یې لګښت نه دی: یو لېږد، یو bond یا یو deploy لا هم د پورتني جدول خپل ثابت لږترلږه حد ورکوي. wallet دواړه ارزښتونه پخپله اعلانوي.

بیې بدلېږي. د chain 20 gas برخه یو dynamic کنټرولر لري، نو gas_price او byte_price د دفتر حالت دي، چې په state root کې ژمن شوي دي. په هر بلاک کې یو ځل، د هغه له راکړو ورکړو وروسته، هر یو د دې له مخې بدلېږي چې بلاک د یوه هدف په پرتله څومره ډک و:

price' = min(max_price, max(min_price, price + ⌊price × adjust_bps × (used − target) / (10,000 × target)⌋))

used د هدف په دوه برابره کې محدودېږي، نو adjust_bps تر ټولو لوی بدلون دی چې یو بلاک یې په هر لوري کې کولی شي. max_price د genesis پورتنی حد دی؛ chains 18 او 19 هېڅ نه درلود. byte_price د بلاک د ورکړه کوونکو بایټونو پسې ځي (لاندې)؛ gas_price د هغه د غوښتنو او invokes د اعلان شویو حدونو مجموعې پسې ځي، جمع د هر بنډل لپاره 20,479.

هغه بلاک چې له خپلو هدفونو ښکته وي بیې ښکته راولي، نو په یوه آرامه زنځیر کې بیې په ښکتنیو پولو پاتې کېږي. rand_getLimits د سر (tip) اوسنۍ gas_price او byte_price له gas_metering: "circuit"، bundle_gas_limit، adjust_bps سره وړاندې کوي، او له v0.6.8 راهیسې max_gas_price، max_byte_price او byte_load هم (په هغه زنځیر کې چې دا نه لري null)؛ rand_status همدا دوه بیې د gas_prices په نوم راپوروي.

پورتنۍ پولې او د تادیه کوونکو بایټونو بار

دواړه د gas.dynamic د genesis ساحې دي، په v0.6.8 کې نوې (audit v6، POOL-2)، او chain 20 لومړی زنځیر دی چې دا ټاکي. دا هغه نیمګړتیا سموي چې chain 18 او 19 درلوده. هلته byte_price د هرې راکړې ورکړې له کوډ شوي اوږدوالي سره بدلېده، په داسې حال کې چې یوازې کال یې ورکوي. اووه لېږدونه (هر یو شاوخوا 2.85 MB، ثابت فیس) بلاک د بایټ تر هدف شاوخوا 1.9 چنده ډکوي او بیه په هر بلاک کې شاوخوا 11% لوړوي، پرته له کومې پورتنۍ پولې: شاوخوا 65 داسې بلاکونه یې د پیل تر 1,000 چنده رسوي، او بیا یو کال د شاوخوا 0.004 پر ځای شاوخوا 1 RAND لګښت لري.

• پورتنۍ پولې. max_gas_price او max_byte_price هغه بیې دي چې کنټرولر هېڅکله ترې نه پورته کوي. ګام همغه دی او بیا محدودېږي (gas::next_price_capped)، نو هغه بیه چې خپلې پورتنۍ پولې ته رسېدلې وي د ډکو بلاکونو په هر لړۍ کې همالته پاتې کېږي او د هدف لاندې په لومړي بلاک ښکته کېږي. یو genesis باید هره یوه د خپلې پیلنۍ بیې سره برابره یا تر هغې لوړه وټاکي. د chain 20 په پورتنیو پولو کې پورته یاد د tier-14 کال، 20,479 ګاز او 1,319 KiB، 0.3113 RAND ښکتنۍ پوله لري، چې د هغه ښکتنۍ پوله تر دې لوړه نه شي تللی.
• د تادیه کوونکو بایټونو بار. د byte_load: "paying" لاندې د بلاک bytes_used یوازې هغه بایټونه شمېري چې د بایټ بیه پرې اخیستل کېږي: د هر Call او Invoke ثبوت او د ننوتو لفافه (gas::call_bytes)، او د لېږد، تړون (bond) یا سوځولو هېڅ برخه نه. د لېږدونو یو بلاک د بایټ بیه نه خوځوي. Ledger::block_usage دا شمېره هم د وړاندیز کوونکي او هم د ریپلیکا لپاره محاسبه کوي، نو دواړه سره برابر دي.

د تادیه کوونکي بار لاندې، د لېږدونو څخه ډک بلاک کال ته د بیې هېڅ نښه نه ورکوي، نو یو صادق وړاندیز کوونکی د کالونو لپاره هم ځای ساتي. دا د نوډ پالیسي ده، د اعتبار قاعده نه: تر هغه چې یو کال یا یو انووک په پول کې وي او خپله اوسنۍ ښکتنۍ پوله ورکوي، ثابت-فیس لرونکې راکړې ورکړې په لومړي پړاو کې د بلاک تر ټولو زیات درې پر څلورمه بایټونه نیسي، او هغه څه چې کالونه یې له وروستۍ څلورمې برخې پرېږدي بیا په ځنډول شویو لېږدونو ډکېږي (میم‌پول).

والټ د یوه کال لپاره څه ورکوي

rand call لومړی پروګرام په امولېټر کې چلوي او gas: <exact> (declaring <limit>, tier <t>) چاپوي. په ډیفالټ ډول دا دقیق ګاز د 2^(tier − 2) تر مضرب پورې پورته ګردوي او اعلانوي یې؛ --gas-limit N یوه دقیقه شمېره اعلانوي او --gas-limit max د سرلیک پورتنۍ پوله.

دوه شیان ډیفالټ فیس تر ښکتنۍ پولې لوړوي:

• ثبوت د حد په اندازه بیه کېږي. له chain 16 راهیسې (hardening_v6، chain 20 هم پکې) د کال ثبوت له خپلې راکړې ورکړې سره تړل شوی دی، نو فیس د ثبوت له جوړېدو مخکې ټاکل کېږي. والټ د ثبوت د ریښتیني اندازې پر ځای د زنځیر د ثبوت حد، 4 MiB، بیه کوي (wallet::hardened_call_quote_bytes). دا یوازې زیات ورکول کېدای شي.
• د بیې دوه ګامه اضافي ځای. rand_getLimits د ژمن شوي سر بیې وړاندې کوي او کال دوه یا درې بلاکه وروسته ځای نیسي، نو ډیفالټ ښکتنۍ پوله په (1 + adjust_bps / 10,000)² ضربوي، چې په chain 20 کې 1.125² دی.

په chain 18 کې د 2026-09-30 په نېټه اندازه شوي، څلورو کالونو په همدې ډیفالټونو هر یو د 0.0057 او 0.0075 RAND ترمنځ لګښت درلود (بېلګه پروګرامونه). --fee ډیفالټ ځای ناستی کوي؛ والټ د سپارلو مخکې ریښتینی ثبوت بیا بیه کوي او هغه فیس ردوي چې تر ښکتنۍ پولې کم وي.

فیس چېرته ځي

ټول یې — ښکتنۍ پوله او ټیپ — د اعتباروونکو په راجستر کې د بلاک د وړاندیز کوونکي rewards ته ورکول کېږي، چې په دې زنځیر کې یوازینی ځای دی چې یوه اندازه په ښکاره ساتي، له یوې استثنا سره. په هغه genesis کې چې tokens.burn_registration_fee لري (chain 20، لکه له 15 راهیسې هر زنځیر)، د RegisterToken یا RegisterBridgedToken registration_fee سوځول کېږي او وړاندیز کوونکی fee − registration_fee ساتي؛ rand_getSupply دا په registration_fees_burned کې شمېري. په chain 14 کې، چې دا بیرغ یې نه درلود، وړاندیز کوونکي ټول فیس ساته. بل هېڅ شی نه سوځول کېږي او هېڅ وېش نشته. یو اعتباروونکی راټول شوي انعامونه د rand-node withdraw په مرسته په یوه نوټ بدلوي (سټیکنګ). د یوه انووک د حجرې فیس د هغه د بنډل د فیس برخه ده او له پاتې سره یوځای وړاندیز کوونکي ته ځي. په chain 20 کې د بلاک انعامونه او انفلاسیون نشته: فیسونه د یوه اعتباروونکي ټول عاید دی.

په chain 20 کې یو فیس RAND نه دی او هېڅ اعتباروونکي ته نه ځي. د genesis bridge.fees لاندې (په v0.6.8 کې نوی) پُل د هر zUSD زېرمه کولو او هرې zUSD سوځونې 10 bps ساتي، د ملاتړ تر بشپړ خوشې کولو واحد پورې ښکته ګرد شوی، د یوه zUSD نوټ په توګه هغه خزانې پتې ته چې genesis یې نوموي. زېرمه زېرمه کوونکي ته ناخالص له فیس پرته ورکوي؛ سوځونه په سرچینه زنځیر کې amount − fee خوشې کوي. د فیس نوټ صادر او ملاتړ شوی پاتې کېږي. پُل او RPL توکنونه وګورئ.

میم‌پول نوماندان د هغه څه له مخې ترتیبوي چې په هر KiB کې تر خپلې ښکتنۍ پولې زیات ورکوي، بیا د فیس له مخې (میم‌پول)، نو لوړ فیس یوازې د ګڼې ګوڼې پر مهال اهمیت لري. یو لېږد شاوخوا 2.85 MB دی (په chain 18 کې اندازه شوی): د بنډل یو 1.49 MB ثبوت او د اجازې یو 1.36 MB ثبوت، نو شاوخوا اووه یې د chain 20 په 20 MiB بلاک کې ځایېږي. د fullnode خپله یادونه دا وه چې د بایټونو پر بنسټ د فیس بازار — نه د اوپکوډونو پر بنسټ — هغه څه دي چې ښکتنۍ پوله باید له mainnet مخکې پرې بدله شي. د chain 20 د بایټ بیه د کالونو لپاره همدا بازار دی، چې یوازې هغه بایټونه یې خوځوي چې کالونه یې بیه ورکوي؛ د لېږد ښکتنۍ پوله لا هم ثابته ده.

ولې دلته ګاز بیه ده، نه حد

Ethereum هر اوپکوډ اندازه کوي ځکه چې هر نوډ هره راکړه ورکړه اجرا کوي او اجرا پای نه لري. په Rand کې هېڅ نوډ هېڅ شی نه اجرا کوي: لېږونکی پروګرام یو ځل، له زنځیر بهر، چلوي او زنځیر ته یو ثبوت سپاري. په هره راکړه ورکړه کې د نوډ کار یوه ثابته لړۍ ده — عامې ساحې کوډ-خلاصول، وړیا ازموینې چلول، او یو STARK تاییدول — او دا تایید د تاییدوونکي له تود کلي سره شاوخوا 16 ms وخت نیسي، که پروګرام هر څه کړي وي. نو د ګاز درې دندې سره جلا کېږي:

• پای ته رسېدل د پوړ له لارې پلي کېږي: هغه چلېدنه چې په 2ᵗ − 1 دورو کې ونه درېږي هېڅ نه شي ثابتېدای، او ثابتوونکی ناکامي په غاړه اخلي.
• د کار بیه ټاکل هغه څه دي چې د ګاز ښکتنۍ پوله یې له chain 18 راهیسې کوي. د شبکې لګښت په هره لارښوونه کې نږدې صفر دی، خو د لېږونکي د ثابتولو کار ریښتینی دی، او ثابتې ښکتنۍ پولې د میلیون-دورې کال د زر-دورې کال په څېر بیه کاوه. تر chain 18 پورې ښکتنۍ پوله په هر پوړ کې ثابته وه.
• د بلاک اندازه د بایټونو بودیجه ده (MAX_BLOCK_BYTES = په ډیفالټ ډول 4 MiB، که نه نو د genesis max_block_bytes) او د راکړو ورکړو شمېر (2,000).

دوه خبرداري چې fullnode یې په ښکاره وايي: بایټونه توپیر لري (یو ثبوت تر یوه میګابایټ زیات دی، نو کمیاب سرچینه د بلاک ځای دی، نه محاسبه)، او د حالت وده — ونه، د نولیفایر ټولګه، ځای پر ځای شوي پروګرام بایټونه — یوازې د هر کلمې د ځای پر ځای کولو فیس او ثابت بنسټ په واسطه بیه کېږي، چې د یوه testnet لپاره بسنه کوي او کله چې د حالت اندازه مهمه شي د بیا کتنې وړ ده.

د دې پر ځای لېږونکی څه ورکوي: ثابتول

یوازینی لګښت چې توپیر کوي د STARK ثبوت جوړول دي، او یوازې د لېږونکي ماشین یې ورکوي. د اغېز په ترتیب:

1. پوړ t ∈ {10, 12, 14, 16, 18, 20} (له v0.5.6 راهیسې تر 14 پورته کال په زنځیر کې ردېږي؛ بنډل په 14 تړل شوی دی، او له chain 17 راهیسې ورسره د tier-10 د اجازې ثبوت هم لري، چې شاوخوا 7 s نور وخت نیسي): د cpu جدول تر 2ᵗ قطارونو پورې ډکېږي او هر ګام ډک شوی ټریس نږدې څلور چنده کوي. د پراختیا په لپ ټاپ اندازه شوي: private_payment په tier 10 کې شاوخوا 7 s کې؛ د پټې شتمنۍ د بنډل guest په tier 14 کې شاوخوا 100 s کې، هره شتمني چې خوځوي.
2. اجرا شوې دورې، ځکه چې دا پوړ ټاکي: چلېدلې لارښوونې، نه لیکلې لارښوونې.
3. د پروګرام اندازه، په کمزوري ډول: د ټریس په پیل کې د هرو څلورو کلمو لپاره یو ډایجسټ قطار.
4. د خصوصي ننوتو اندازه، په همدې ډول.
5. کوم جدولونه شته: د keccak یا sha256 جدول د خپلو ستنو برخه لګښت یوازې هغه وخت لري چې guest کارولی وي.
6. د FRI پروفایل: د 27 پر ځای 80 پوښتنې د ثبوت اندازه درې چنده کوي خو د ثابتولو وخت په سختۍ بدلوي.

ثابتول په اندازو، په دې چې لېږونکی څو نوټونه لري، یا د زنځیر په اندازه پورې اړه نه لري: غړیتوب د ثابتې ژورتیا لرونکې ونې په وړاندې ثابتېږي، نو یو لېږد په لسم بلاک او لس میلیونم بلاک کې یو شان لګښت لري.

سرچینه