کارمزدها

از این صفحه برای تعیین کارمزد یک تراکنش، برآورد هزینهٔ یک deploy یا یک call، و فهم آنچه به یک اعتبارسنج پرداخت می‌شود استفاده کنید. کارمزدها کف‌هایی بر حسب RAND هستند. هر اقدامی جز call کارمزدی ثابت می‌پردازد. در chain 20 یک call برای سقف گسی که اثباتش اعلام می‌کند و برای بایت‌هایش می‌پردازد، با قیمت‌هایی که با میزان پُر بودن بلوک‌ها تغییر می‌کنند و در یک سقف متوقف می‌شوند.

کف‌ها

کارمزدها بر حسب واحدهای 10⁻⁹ RAND هستند. ثابت‌ها در randprotocol_core::gas قرار دارند:

کارمزد یک کلمهٔ عمومی از bundle است و همیشه RAND است. guest مربوط به bundle دارایی پنهان آن را به رابطهٔ تراز گروه RAND پیوند می‌دهد، in₂ + in₃ = out₂ + out₃ + fee + burn_r (اسلات‌های 2–3)، بنابراین از نوت‌های پنهان پرداخت می‌شود بی‌آنکه معلوم شود از کدام؛ یک توکن از اسلات‌های 0–1 همان bundle و تحت رابطهٔ خودش جابه‌جا می‌شود، in₀ + in₁ = out₀ + out₁ + burn_a. بنابراین یک اثبات هم توکن را جابه‌جا می‌کند و هم کارمزد RAND آن را می‌پردازد، و کیف پولی که توکن دارد اما RAND قابل‌خرج ندارد پیش از اثبات‌سازی رد می‌شود.

هزینهٔ پل بر burn می‌افتد، چون burn تنها تراکنش پل است که فرستندهٔ آن حتماً RAND دارد؛ یک واریز فقط پایه را می‌پردازد، زیرا واریزکننده هنوز RAND ندارد. کارمزد ثبت یک واقعیت دفتری است و بخشی از fee_floor نیست، بنابراین با قواعد خود آن اقدام بررسی می‌شود (RegistrationFeeTooLow)، همان‌طور که بخش گس یا tier یک call پس از رمزگشایی اثبات آن دریافت می‌شود. کف یک call دو بار بررسی می‌شود، زیرا آنچه اعلام می‌کند فقط پس از تأیید اثباتش قابل اعتماد است. در chain 20 بررسی اول، پیش از هر تأییدی، بایت‌های call و سقف اعلامی 1 را قیمت‌گذاری می‌کند (یک Invoke در آنجا کارمزد سلول خود را هم بدهکار است)؛ بررسی دوم سقفی را قیمت‌گذاری می‌کند که اثبات تأییدشده اعلام می‌کند. در زنجیره‌ای بدون بخش gas این دو BUNDLE_BASE + CALL_BASE و کف دقیق tier هستند.

به‌جای حدس زدن از نود بپرسید:

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 با قیمت‌های آغازین است؛ نود هر قیمتی را که در نوک زنجیره برقرار باشد در زمان پرسش به‌کار می‌برد. در chain 20 فیلد gas در مشخصهٔ call روی JSON-RPC الزامی است (بدون آن -32602). rand fee call <tier> بدون --gas سقف tier را می‌فرستد و بدون --bytes هیچ بایتی را قیمت‌گذاری نمی‌کند. یک invoke به همین ترتیب قیمت‌گذاری می‌شود، با "kind":"invoke" و "created_cells": c که c کارمزد سلول اضافه می‌کند (24103100 برای مثال بالا با دو سلول، که در 2026-10-01 از chain 20 پرسیده شد). در chain 15، که بخش gas نداشت، rand fee call 14 پاسخ 0.0022 RAND داد.

پیش‌فرض‌های کیف پول دقیقاً همان کف‌ها هستند، جز برای call در chain 20 که پیش‌فرضش حاشیه‌ای اضافه دارد (در ادامه); rand send --fee <RAND> و پرچم --fee روی bond، call، bridge-mint، bridge-burn (پیش‌فرض 0.01) و زیردستورهای token آن‌ها را بالا می‌برند. هر مقدار بالاتر از کف یک انعام است.

گس در chain 18

chain 18، که از 2026-09-29 تا 2026-10-01 فعال بود، نخستین زنجیرهٔ گس‌سنجی‌شده بود و chain 19، که re-genesis آن روی همان build بود، همان بخش gas را داشت. chain 20 (v0.6.8) همهٔ قواعد این بخش را نگه می‌دارد و دو سقف قیمت و یک بار بایت را اضافه می‌کند که فقط روی بایت‌های پرداختی شمرده می‌شود (در ادامه). زنجیره‌ای بدون بخش gas برنامهٔ tier را در جدول بالا نگه می‌دارد.

آنچه شمرده می‌شود. یک گس برابر یک سطر از جدول cpu در zkVM است، بنابراین یک دستورالعمل معمولی 1 هزینه دارد. فراخوان‌های سیستمی تنها هزینه‌های دیگرند:

سقف اعلامی. اثبات یک call یک مقدار عمومی بیشتر از پیش حمل می‌کند، GAS_LIMIT، و مدار (مجموعهٔ قیود 8) ثابت می‌کند که گس اجرا برابر آن یا کمتر از آن است. گس دقیق خصوصی می‌ماند. سقفی بالاتر از سقف هدر خود اثبات پیش از ساخته شدن هر کلید verifier رد می‌شود:

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

این برابر 1,279 در tier 10، 5,119 در tier 12 و 20,479 در tier 14 برای callی است که هیچ‌یک از دو جدول هش را به‌کار نمی‌برد.

کف. دفتر سقف اعلامی و بایت‌ها را با قیمت‌های برقرار در آغاز بلوک دریافت می‌کند:

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

bytes اثبات call به‌علاوهٔ پاکت ورودی است. برنامهٔ tier و سهمیهٔ رایگان آن در چنین زنجیره‌ای اعمال نمی‌شود. استخر دقیقاً همان را می‌طلبد که یک بلوک می‌طلبد، و callی ارزان‌تر را با FeeTooLow رد می‌کند.

bundleها و اثبات مجوز سقف‌های ثابت اعلام می‌کنند. هر اثبات bundle باید دقیقاً bundle_gas_limit در genesis را اعلام کند، یعنی 20,479 (سقف tier 14)، وگرنه تراکنش با BundleGasLimit رد می‌شود. chain 20، مانند هر زنجیره از 17 به بعد، مجوزدهی تقسیم‌شده اجرا می‌کند، بنابراین هر bundle یک اثبات مجوز از tier 10 حمل می‌کند که باید 1,279 را اعلام کند (AuthGasLimit). هیچ‌کدام یک هزینه نیست: یک انتقال، یک bond یا یک deploy همچنان کف ثابت خود را از جدول بالا می‌پردازد. کیف پول هر دو مقدار را خودش اعلام می‌کند.

قیمت‌ها حرکت می‌کنند. بخش gas در chain 20 یک کنترل‌کنندهٔ dynamic دارد، بنابراین gas_price و byte_price وضعیت دفتر هستند و در ریشهٔ وضعیت commit می‌شوند. یک بار در هر بلوک، پس از تراکنش‌هایش، هر کدام بر اساس میزان پُر بودن بلوک نسبت به یک هدف حرکت می‌کند:

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

used به دو برابر هدف محدود می‌شود، بنابراین adjust_bps بزرگ‌ترین حرکتی است که یک بلوک می‌تواند در هر جهت انجام دهد. max_price سقف genesis است؛ chain 18 و chain 19 سقفی نداشتند. byte_price از بایت‌های پرداختی بلوک پیروی می‌کند (در ادامه)؛ gas_price از مجموع سقف‌های اعلامی callها و invokeهای آن به‌علاوهٔ 20,479 برای هر bundle پیروی می‌کند.

بلاکی که زیر هدف‌هایش باشد قیمت‌ها را پایین می‌برد؛ بنابراین در زنجیره‌ای کم‌تردد قیمت‌ها روی کف می‌مانند. rand_getLimits مقادیر جاری 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 گزارش می‌کند.

سقف‌ها و بار بایتیِ پرداختی

هر دو فیلدهای genesis در gas.dynamic هستند، از v0.6.8 اضافه شده‌اند (audit v6، POOL-2) و chain 20 نخستین زنجیره‌ای است که آن‌ها را مقداردهی می‌کند. این دو یک نقص را برطرف می‌کنند که chain 18 و chain 19 داشتند. در آن زنجیره‌ها byte_price با طول رمزگذاری‌شدهٔ هر تراکنش جابه‌جا می‌شد، در حالی که فقط یک call آن را می‌پردازد. هفت انتقال (هرکدام حدود 2.85 MB، با کارمزد ثابت) بلاک را تا حدود 1.9 برابر هدف بایتی پر می‌کنند و قیمت را حدود 11% در هر بلاک بالا می‌برند، آن هم بدون سقف: حدود 65 بلاک از این دست آن را به 1,000 برابر قیمت آغازینش می‌رساند و آنگاه یک call به‌جای حدود 0.004 حدود 1 RAND هزینه دارد.

• سقف‌ها. max_gas_price و max_byte_price قیمت‌هایی هستند که کنترل‌کننده هرگز از آن‌ها فراتر نمی‌برد. گام همان است و سپس برش می‌خورد (gas::next_price_capped)؛ پس قیمتی که به سقف رسیده باشد در هر رشته از بلاک‌های پر همان‌جا می‌ماند و در نخستین بلاکِ زیر هدف پایین می‌آید. genesis باید هر یک را برابر یا بالاتر از قیمت آغازینش تعیین کند. در سقف‌های chain 20، کف هزینهٔ call از رده 14 در بالا، یعنی 20,479 gas و 1,319 KiB، برابر 0.3113 RAND است، که بالاترین مقداری است که کف آن می‌تواند بگیرد.
• بار بایتیِ پرداختی. تحت byte_load: "paying"، مقدار bytes_used بلاک فقط بایت‌هایی را می‌شمارد که قیمت بایت بر آن‌ها اعمال می‌شود: اثبات به‌علاوهٔ پاکت ورودیِ هر Call و Invoke (gas::call_bytes)، و هیچ چیز از یک انتقال، یک bond یا یک burn. بلاکی از انتقال‌ها قیمت بایت را جابه‌جا نمی‌کند. Ledger::block_usage این مقدار را هم برای پیشنهاددهنده و هم برای replica محاسبه می‌کند، پس این دو با هم یکسان‌اند.

تحت بار پرداختی، بلاکی پر از انتقال هیچ سیگنال قیمتی به call نمی‌دهد؛ از این رو یک پیشنهاددهندهٔ درستکار برای callها هم جا نگه می‌دارد. این سیاست node است، نه قاعدهٔ اعتبار: تا وقتی یک call یا invoke در استخر منتظر است و کف جاری را می‌پردازد، تراکنش‌های با کارمزد ثابت در گذر نخست حداکثر سه‌چهارم بایت‌های بلاک را می‌گیرند، و آنچه callها از یک‌چهارم پایانی باقی بگذارند با انتقال‌های نگه‌داشته‌شده پر می‌شود (Mempool).

آنچه کیف پول برای یک call می‌پردازد

rand call ابتدا برنامه را در شبیه‌ساز اجرا می‌کند و gas: <exact> (declaring <limit>, tier <t>) را چاپ می‌کند. به‌طور پیش‌فرض، gas دقیق را به بالا و تا مضرب 2^(tier − 2) گرد می‌کند و اعلام می‌دارد؛ --gas-limit N مقداری دقیق اعلام می‌کند و --gas-limit max سقف header را.

دو چیز کارمزد پیش‌فرض را بالاتر از کف می‌برند:

• اثبات به قیمت سقف تعرفه می‌شود. از chain 16 (hardening_v6، از جمله chain 20) اثبات یک call به تراکنش خودش گره خورده است، پس کارمزد پیش از وجود اثبات تثبیت می‌شود. کیف پول به‌جای اندازهٔ واقعی اثبات، سقف اثبات زنجیره یعنی 4 MiB را قیمت‌گذاری می‌کند (wallet::hardened_call_quote_bytes). این فقط می‌تواند بیش‌پرداخت باشد.
• دو گام قیمتی حاشیهٔ امن. rand_getLimits قیمت‌های سر زنجیرهٔ تأییدشده را برمی‌گرداند و یک call دو یا سه بلاک بعد در زنجیره می‌نشیند؛ بنابراین مقدار پیش‌فرض کف را در (1 + adjust_bps / 10,000)² ضرب می‌کند که در chain 20 برابر 1.125² است.

در chain 18 در تاریخ 2026-09-30 اندازه‌گیری شد: چهار call با این پیش‌فرض‌ها هرکدام بین 0.0057 و 0.0075 RAND هزینه داشتند (Example programs). --fee پیش‌فرض را بازنویسی می‌کند؛ کیف پول پیش از ارسال اثبات واقعی را دوباره قیمت‌گذاری می‌کند و کارمزدی زیر کف را رد می‌کند.

کارمزد به کجا می‌رود

همهٔ آن — کف و انعام — به rewards پیشنهاددهندهٔ بلاک در دفتر ثبت اعتبارسنج‌ها واریز می‌شود، یعنی تنها جایی در این زنجیره که مبلغی را آشکار ذخیره می‌کند، با یک استثنا. در genesis ای که tokens.burn_registration_fee دارد (chain 20، مانند هر زنجیره از 15 به بعد)، registration_fee یک RegisterToken یا RegisterBridgedToken سوزانده می‌شود و پیشنهاددهنده fee − registration_fee را نگه می‌دارد؛ rand_getSupply آن را در registration_fees_burned می‌شمارد. در chain 14 که این پرچم را نداشت، پیشنهاددهنده کل کارمزد را نگه می‌داشت. هیچ چیز دیگری سوزانده نمی‌شود و تقسیمی در کار نیست. یک اعتبارسنج پاداش‌های انباشته را با rand-node withdraw به یک یادداشت تبدیل می‌کند (Staking). کارمزد سلول یک invoke بخشی از کارمزد بسته‌اش است و همراه با بقیه به پیشنهاددهنده می‌رسد. در chain 20 نه پاداش بلاک وجود دارد و نه تورم: کارمزدها تمام درآمد یک اعتبارسنج‌اند.

یک کارمزد در chain 20 از جنس RAND نیست و به هیچ اعتبارسنجی نمی‌رسد. بر اساس bridge.fees در genesis (جدید در v0.6.8)، پل 10 bps از هر واریز zUSD و هر burn zUSD را، گرد شده به پایین تا یک واحد کامل آزادسازیِ پشتوانه، به‌صورت یک یادداشت zUSD نزد نشانی خزانه‌ای که genesis نام می‌برد نگه می‌دارد. یک واریز، ناخالص منهای کارمزد را به واریزکننده اعتبار می‌دهد؛ یک burn مقدار amount − fee را در زنجیرهٔ مبدأ آزاد می‌کند. یادداشت کارمزد همچنان صادرشده و پشتوانه‌دار می‌ماند. نگاه کنید به Bridge و RPL tokens.

mempool نامزدها را بر اساس آنچه به ازای هر KiB بالاتر از کف خود می‌پردازند مرتب می‌کند، سپس بر اساس کارمزد (Mempool)، پس کارمزد بالاتر فقط در ازدحام اهمیت دارد. یک انتقال حدود 2.85 MB است (اندازه‌گیری‌شده در chain 18): یک اثبات بسته به اندازهٔ 1.49 MB و یک اثبات مجوز به اندازهٔ 1.36 MB، پس حدود هفت انتقال در بلاک 20 MiB زنجیرهٔ chain 20 جا می‌شود. یادداشت خود fullnode این بود که بازار کارمزد روی بایت‌ها، نه روی opcodeها، همان چیزی است که کف باید پیش از mainnet به آن تبدیل شود. قیمت بایت در chain 20 همان بازار برای callهاست و فقط با بایت‌هایی جابه‌جا می‌شود که callها بابتشان می‌پردازند؛ کف یک انتقال همچنان ثابت است.

چرا gas در اینجا یک قیمت است، نه یک کران

Ethereum هر opcode را اندازه می‌گیرد زیرا هر node هر تراکنش را اجرا می‌کند و اجرا بی‌پایان است. در Rand هیچ nodeای چیزی را اجرا نمی‌کند: فرستنده برنامه را یک بار، خارج از زنجیره، اجرا می‌کند و یک اثبات به زنجیره می‌دهد. کار یک node به ازای هر تراکنش دنباله‌ای ثابت است — رمزگشایی فیلدهای عمومی، اجرای بررسی‌های رایگان، تأیید یک STARK — و این تأیید با کلید تأییدکنندهٔ گرم حدود 16 ms طول می‌کشد، فارغ از آنکه برنامه چه کرده باشد. بدین‌سان سه کار gas از هم جدا می‌شوند:

• خاتمه را رده تضمین می‌کند: اجرایی که در 2ᵗ − 1 چرخه متوقف نشود اصلاً قابل اثبات نیست و اثبات‌کننده شکست را جذب می‌کند.
• قیمت‌گذاری کار همان است که کف gas از chain 18 انجام می‌دهد. هزینهٔ شبکه به ازای هر دستور نزدیک به صفر است، اما کار اثبات فرستنده واقعی است و کفِ ثابت یک call میلیون‌چرخه‌ای را مانند یک call هزارچرخه‌ای قیمت می‌زد. تا پیش از chain 18 کف به ازای هر رده ثابت بود.
• اندازه‌گذاری بلاک یک بودجهٔ بایتی است (به‌طور پیش‌فرض MAX_BLOCK_BYTES = 4 MiB، و در غیر این صورت max_block_bytes در genesis) و یک شمار تراکنش (2,000).

دو هشدار که fullnode آشکارا بیان می‌کند: بایت‌ها واقعاً تغییر می‌کنند (یک اثبات بیش از یک مگابایت است، پس منبع کمیاب فضای بلاک است، نه محاسبه)، و رشد state — درخت، مجموعهٔ nullifierها، بایت‌های برنامه‌های مستقرشده — فقط با کارمزد استقرار به ازای هر کلمه و پایهٔ ثابت قیمت‌گذاری می‌شود، که برای یک testnet بسنده است و وقتی اندازهٔ state اهمیت یابد شایستهٔ بازنگری است.

فرستنده در عوض چه می‌پردازد: اثبات‌سازی

تنها هزینه‌ای که تغییر می‌کند تولید اثبات STARK است و فقط دستگاه فرستنده آن را می‌پردازد. به ترتیب تأثیر:

1. رده t ∈ {10, 12, 14, 16, 18, 20} (از v0.5.6 زنجیره callی بالاتر از 14 را رد می‌کند؛ یک bundle روی 14 ثابت است و از chain 17 یک اثبات مجوز رده 10 را در کنار خود دارد، حدود 7 s بیشتر): جدول cpu تا 2ᵗ سطر پر می‌شود و هر گام ردِ پرشده را تقریباً چهار برابر می‌کند. اندازه‌گیری روی لپ‌تاپ توسعه: private_payment در رده 10 در حدود 7 s؛ guest مربوط به bundle دارایی پنهان در رده 14 در حدود 100 s، به هر دارایی‌ای که جابه‌جا کند.
2. چرخه‌های اجراشده، زیرا رده را تعیین می‌کنند: دستورهای اجراشده، نه دستورهای نوشته‌شده.
3. اندازهٔ برنامه، به‌طور ضعیف: یک سطر digest به ازای هر چهار کلمه در آغاز ردّ.
4. اندازهٔ ورودی خصوصی، به همان شیوه.
5. کدام جدول‌ها حضور دارند: یک جدول keccak یا sha256 سهم ستون‌های خود را فقط وقتی می‌پردازد که guest از آن استفاده کرده باشد.
6. پروفایل FRI: 80 پرس‌وجو به‌جای 27 اندازهٔ اثبات را سه برابر می‌کند اما زمان اثبات‌سازی را به‌ندرت تغییر می‌دهد.

اثبات‌سازی به مبالغ، به تعداد یادداشت‌هایی که فرستنده دارد، یا به اندازهٔ زنجیره بستگی ندارد: عضویت در برابر درختی با عمق ثابت اثبات می‌شود، پس یک انتقال در بلاک ده همان‌قدر هزینه دارد که در بلاک ده میلیون.

مرجع