پروګرامونه

دا پاڼه وکاروئ ترڅو یو پروګرام په چین کې ځای پر ځای کړئ او ویې بولئ: پروګرام څه دی، څنګه جوړېږي، یو کال څه خپروي او څه پټوي، رسید څنګه بېرته لوستل کېږي، او هغه حدونه چې ورسره به مخ شئ. هر پروګرام عامه کوډ دی؛ هر کال یو ثبوت دی. د بېلګې پروګرامونه بشپړ اپلیکېشنونه لري، او randprotocol/example-programs د هغو پروګرامونو سرچینه لري چې په chain 20 کې ځای پر ځای شوي، د RPL-2 پروګرامونو په ګډون (لاندې).

پروګرام څه دی

پروګرام د Rand zkVM لپاره RV32IM ماشیني کوډ دی: { base_pc: u32, words: Vec<u32> }، چې تر ډېره د چین د پروګرام حد پورې وي (په chain 20 کې 65,535 کلمې، لکه له chain 13 راهیسې په هر چین کې؛ په هغه genesis کې چې max_program_words نه لري، لکه chain 12، 4,096)، base_pc د 4 مضرب وي، او هره کلمه د یوې لارښوونې په توګه ډیکوډ شي (هغه کلمه چې ډیکوډ نه شي د ځای پر ځای کولو پر مهال رد کېږي، هېڅکله د اجرا پر مهال نه). chain 20، لکه chain 19، هغه پروګرام هم نه مني چې هېڅ کال یې نه شي ځایولی: له 8,180 کلمو ډېر کله چې عامه برخه ونه لري، او لږ کله چې یوه ولري (لاندې). دا د محتوا له مخې پته لري او نه بدلېدونکی دی:

program_id = blake3("rand-program" || base_pc || words)       // the id, with no public input
program_id = blake3("rand-program-2", base_pc || u32_le(len(words)) || words || u32_le(len(public)) || public)   // deployed with --public
code_hash  = hc = Poseidon2 digest of (base_pc, len, words)    // what calls are verified against

کال یو STARK ثبوت دی چې هغه پروګرام چې ډایجسټ یې hc دی په ځینو خصوصي ننوتو چلېدلی، له اعلان شوي ګاز حد څخه یې زیات نه دي لګولي، او اته د وتو کلمې یې خپرې کړې. نوډ ثبوت تاییدوي، رسید ثبتوي، او نور هېڅ نه کېږي: وتنې معلومات دي، اغېزې نه. یو کال RAND نه شي لېږدولی؛ کال کوونکی ارزښت په هغه بنډل کې لېږدوي چې د کال فیس ورکوي، او د یو پروګرام وتنې هماغه مانا لري چې پروګرام او کال کوونکی یې پرې موافق وي. په chain 20 کې Invoke استثنا ده: ثبوت یې د یو اعلان شوي حالت بدلون تضمینوي، چې بیا یې لېجر پلی کوي (د پروګرام حالت (RPL-2)).

ګېسټ څه کولی شي:

سیسټم کالونه، په a7 کې د شمېرې له مخې:

حافظه: 32 ریجسټرونه چې x0 یې صفر دی؛ RAM چې له صفر پیلېږي؛ هره پته له 2³⁰ لاندې؛ د کمپایل شویو ګېسټونو لپاره 64 KiB سټک. هغه پروګرام چې د rand-guest سره جوړ شوی وي، خپل یوازې د لوستلو وړ او پیل شوي معلومات د انځور په کانټېنر کې وړي، او د بارونکي یوه سریزه چې د پروګرام برخه ده، دا معلومات د پروګرام د خپل کوډ له چلېدو مخکې لیکي (The RISC-V ISA). د نوټ ژمنې، nullifiers او Merkle ازموینې سیسټم کالونه نه دي، بلکې د POSEIDON2 پر سر د کتابتون روټینونه دي.

له chain 18 (د محدودیتونو ټولګه 8) راهیسې هره اجرا په ګاز اندازه کېږي. یوه عادي لارښوونه او سیسټم کالونه 0، 1، 2 او 6 هر یو 1 ګاز لګوي، POSEIDON2 پر n کلمو 3 + 3 × ⌈n / 4⌉ لګوي، یو KECCAK پرمیوټېشن 192 لګوي او یو SHA256 کمپرېشن 64 لګوي. د بېلګې پروګرامونه جدول لري او دا چې یو کال څه اعلانوي.

د یو پروګرام جوړول

درې لارې، چې ټولې RV32IM کلمې جوړوي:

جوړ شوی اسمبلر. والټ پنځه په لاس اسمبل شوي ګېسټونه لري او هغوی یوې { "base_pc", "words" } JSON فایل ته اسمبلوي:

rand program build --guest private_payment --arg 1000 --out pp.json   # prints the program id
rand program build --guest balance_check --arg 1000 --out bc.json
# guests: fib, memcpy, bubble_sort, balance_check, private_payment, public_echo, rpl2_counter (v0.6.8); --arg is repeatable

کمپایل شوي پروګرامونه، د rand-guest سره. د circuits ذخیرې rand-guest یو no_std Rust کرېټ (riscv32im-unknown-none-elf، Rust 1.98.1) یا یو C ډایرکټري (clang 23.1.1) د انځور په کانټېنر جوړوي، هره کلمه د ماشین د ډیکوډر پر وړاندې ازمويي، او hc او د پروګرام id چاپوي. جوړونه هرمېټیک ده، نو یوه سرچینه په هر ماشین کې یو شان hc ورکوي. د chain 18 تر 20 پورې لپاره، ټول‌چین د circuits په aeacf31 کمېټ (څانګه feat/v067-circuits) کې جوړ کړئ، هغه کمېټ چې fullnode v0.6.7 او v0.6.8 دواړه یې ټاکي. په دې کمېټ کې rand-guest check یوازې سیسټم کالونه 0 تر 6 لیست کوي، نو هغه ګېسټ چې guest_sdk::poseidon2_len (سیسټم کال 7) بولي د جوړونې پر مهال ردېږي، که څه هم ماشین یې چلوي (zkp-circuits issue #1). ګام په ګام: یو Rust پروګرام ځای پر ځای کړئ او یو RISC-V پروګرام ځای پر ځای کړئ.

ژباړل شوي پروګرامونه. sbpf2rv یو Solana sBPF ELF، او evm2rv د EVM د اجرا بایټ‌کوډ، داسې پروګرامونو ته ژباړي چې وتنې یې کلمه په کلمه د Rand له مفسر ګېسټونو سره برابرې وي: د Solana ټرانسپایلر او د Ethereum ټرانسپایلر.

والټ پخپله کمپایلر نه لري. rand program deploy یو .json، د little-endian کلمو یو خام .bin، یا هغه د انځور کانټېنر مني چې rand-guest یې لیکي (fullnode v0.3 او وروسته).

ځای پر ځای کول

rand program deploy pp.json          # a bundle pays the floor; waits for the commit; prints the id
rand program show <id>               # id, base_pc, words_len, code_hash, deployed_at, public_words_len, public_digest

testnet چین 20 دی، او پر هغه د ځای پر ځای کولو، کال کولو یا invoke کولو لپاره د fullnode v0.6.8 یا وروسته rand والټ ته اړتیا ده. یو زوړ والټ هلته هېڅ نه شي لېږلی: د chain 20 genesis binding_domain: 1 ټاکي، نو هر د ثبوت تړنه او هر لاسلیک شوی پیغام د genesis هش لري، او د v0.6.7 والټ تړنې یوازې د چین id لري. عامه انډپواینټ https://rpc.randprotocol.org د والټ همغږي، ځای پر ځای کول او کالونه چمتو کوي (تنظیم).

والټ لومړی د پروګرام id، د کلمو شمېر او hc چاپوي، او له نوډ څخه د rand_estimateFee له لارې فیس پوښتي، چې د هر ډول ثبوت جوړولو مخکې هغه پروګرام ردوي چې له چین له حد څخه زیات وي. بیا یو صفر ارزښت لرونکی ځان ته لېږد بنډل جوړوي (هغه یو 4-ننوتې-4-وتنې پټ-شتمنۍ بنډل چې هره راکړه ورکړه یې لري؛ فیس یې له RAND سلاټونو وځي) چې 0.001 RAND + 100,000 units × words له خپلو نوټونو ورکوي (د عامې برخې کلمې د کوډ کلمو په توګه شمېرل کېږي)، Action::Deploy { base_pc, words, public } ورسره نښلوي، بنډل د راکړې ورکړې د تړنې پر وړاندې ثابتوي او وړاندې کوي. له chain 17 راهیسې دا دوه ثبوتونه دي، او والټ د هر یو لپاره یوه کرښه چاپوي: د tier-10 د لګښت اجازه (څو ثانیې، شاوخوا 1.37 MB) او د tier-14 بنډل (په لپ‌ټاپ کې شاوخوا دوه دقیقې، شاوخوا 1.5 MB). له chain 17 مخکې یوازې د بنډل ثبوت و، په chain 15 کې شاوخوا 100 s او شاوخوا 1.42 MB. د ځای پر ځای کولو فیس د ګاز یا بایټ برخه نه لري: ګاز یوازې د کالونو بیه ټاکي. نوډ ازمويي چې هره کلمه ډیکوډ شي، hc محاسبه کوي، ریکارډ زېرمه کوي، او په شالید کې د تاییدوونکي د کلي جوړول پیلوي. کوډ عامه دی؛ چا چې یې پیسې ورکړې، هغه نه دی — rand_getProgram د deployer ساحه نه لري. د یو شان کلمو دوه ځله ځای پر ځای کول idempotent دي.

→ {"method":"rand_getProgram","params":["675adeea…0065"]}
← { "id": "675adeea…0065", "base_pc": 0, "words_len": 42, "code_hash": "…", "deployed_at": 10,
    "public_words_len": 0, "public_digest": null }
→ {"method":"rand_getProgramCode","params":["675adeea…0065"]}
← { "base_pc": 0, "words": [ … ] }

کال کول

rand call <program id> --input 400 --input 250 --input 300 --input 75
rand receipt <tx hash>

والټ کوډ او عامه برخه له نوډ څخه راوړي او ازمويي چې هش یې له id سره برابر وي. کال په ایمولېټر کې چلوي او د هر ډول ثبوت جوړولو مخکې ګاز او فیس چاپوي:

gas: 5636 (declaring 6144, tier 12)
fee 0.006191437 RAND (incl. two price steps of headroom)

بیا د ننوتو ټرانسکرېپټ مهر کوي (لاندې)، کال په محلي ډول د چین د FRI پروفایل لاندې ثابتوي چې ننوتې یې خصوصي وکټور وي، هغه بنډل ثابتوي چې فیس ورکوي، وړاندې کوي یې، انتظار باسي، او رسید چاپوي. په chain 20 کې د کال ثبوت له خپلې راکړې ورکړې سره تړل شوی (هغه تړنه چې د genesis هش لري) او بنډل دوه ثبوتونه دي، نو یو کال درې ثبوتونه دي: کال، د tier-10 د لګښت اجازه او د tier-14 بنډل. پورتنۍ دوه کرښې په chain 18 کې د 2026-09-30 پر نېټه د ناڅرګندې رایې له کال څخه دي (ناڅرګنده رایه).

فیس. په زنځیر 20 کې لږ تر لږه فیس BUNDLE_BASE + gas_price × declared gas limit + byte_price × ⌈bytes / 1024⌉ دی. دلته BUNDLE_BASE 0.001 RAND دی، بایټونه د غوښتنې ثبوت او د ننوتو پاکټ دي، او بیې له 100 او 800 واحدونو (هر واحد 10⁻⁹ RAND دی) پیل شوې او د بلاک له ډکوالي سره بدلېږي. زنځیر 20 یې په 10,000 او 80,000 واحدونو محدودوي. یوازې هغه بایټونه چې د بایټ بیه ورکوي (د غوښتنو ثبوتونه او پاکټونه) د هغې په بار کې شمېرل کېږي (byte_load: "paying"). په 18 او 19 زنځیرونو کې بیې کوم سقف نه درلود او د هرې راکړې ورکړې بایټونو د بایټ بیه بدلوله. د دفتر ثابت مهالوېش 0.001 RAND + call_fee(tier)، چې په زنځیر 15 کې قاعده وه، هلته نه پلي کېږي. والټ فیس د ثبوت له جوړېدو مخکې ټاکي، نو ثبوت د زنځیر د 4 MiB سقف پر بنسټ بیه کوي او د احتیاط لپاره دوه د بیې پړاوونه ورزیاتوي. په زنځیر 18 کې څلور اندازه شوې غوښتنې هره یوه له 0.0057 تر 0.0075 RAND لګښت درلود (حساب). rand fee call <tier> --gas <limit> --bytes <B> لږ تر لږه فیس پخپله له نوډ څخه پوښتي. private_payment څلور خصوصي بیلانسونه لولي او که مجموعه یې لږ تر لږه د هغه حد سره برابره وي، اضافي اندازه خپروي. وتنې یې دا دي: [1, 0, 25, 0, 0, 0, 0, 0]. زنځیر ثبوت، کچه او همدا اته کلمې ویني. بیلانسونه هېڅکله نه ویني.

بیرغونه: --tier T یوه کچه په زور ټاکي. --gas-limit <N|max> د ډیفالټ پر ځای یو دقیق د ګاز حد یا د کچې سقف اعلانوي. دقیق ګاز د 2^(tier − 2) تر مضرب پورې پورته ګردېږي. --fee <RAND> فیس ټاکي. --expect-public <FILE> له ثبوت جوړولو مخکې ردوي، مګر دا چې د پروګرام عامه برخه د هغې فایل کلمې وي. --auditor <rand1…> ثبت د یو نومول شوي پلټونکي لپاره هم مهر کوي. --print-call-key د هرې غوښتنې کیلي چاپوي. --no-envelope هېڅ ثبت نه خپروي. --cuda د GPU شاتنی سیستم ټاکي (په هارډوېر نه دی ازمویل شوی، او د پاکټ له مهرولو سره سمون نه لري). زنځیر 20 پر غوښتنه --cuda په بشپړه توګه ردوي: هغه ثبوت چې له خپلې راکړې ورکړې سره تړلی وي د CPU پر شاتني سیستم جوړېږي.

رسیدونه

د هرې ثبت شوې غوښتنې لپاره یو رسید ساتل کېږي او کله چې یو نوډ خپل زنځیر همغږی یا تایید کړي، بیا محاسبه کېږي:

→ {"method":"rand_getReceipt","params":["b082…09b0"]}
← { "tx": "b082…09b0", "program": "675adeea…0065", "tier": 14,
    "outputs": [1, 0, 25, 0, 0, 0, 0, 0], "height": 105, "index": 0, "h_in": "9c0e…7f", "h_pub": null }

h_in خصوصي ننوتو ته د ثبوت مالګه لرونکې ژمنه ده. پخپله هېڅ نه افشا کوي. h_pub د پروګرام د ځای پر ځای کېدو د وخت عامې برخې ډایجسټ دی، یعنې د پروګرام public_digest، او هغه پروګرام چې پرته له عامې برخې ځای پر ځای شوی وي، دا یې null دی. د effect په نوم کوم ساحه نشته، او اعلان شوی د ګاز حد په رسید کې نه دی. سپړونکی د call لپاره همدا شی د receipt په توګه په GET /transactions/:hash کې ښيي، د یو پروګرام غوښتنې په GET /programs/:id کې لېست کوي، او GET /transactions?kind=call&program=<id> فلټروي.

د ننوتو پاکټونه: وروسته د غوښتنې افشا کول

په ډیفالټ ډول rand call د غوښتنې د (salt, inputs) ثبت په یو د غوښتنې د ننوتو پاکټ کې مهر شوی خپروي، ترڅو ننوتې وروسته پرته له دویم ثبوت څخه وښودل شي:

د متن تړلي معلومات H_IN دي، نو هغه پاکټ چې بلې غوښتنې ته ولېږدول شي د هېچا لپاره نه خلاصېږي. زنځیر یوازې اندازه کتي (تر ټولو زیات max_call_envelope_bytes: په زنځیر 20 کې 65,536 بایټه، او په هغه پیدایښت کې چې دا ساحه نه لري 18,432) او هغه له rand_getCallEnvelope(tx) سره بې له بدلون وړاندې کوي. درې کیلي یې خلاصوي او نور هېڅ: د غوښتونکي د لید کیلي (ټولې هغه غوښتنې چې هغه والټ کړې دي)، د هرې غوښتنې کیلي (یوازې همغه یوه غوښتنه)، او د پلټونکي د لید کیلي (یوازې همغه یوه غوښتنه).

rand open-call <txhash>                    # as the caller
rand open-call <txhash> --as-auditor       # as the auditor
rand open-call <txhash> --call-key <hex>   # with the per-call key alone

open-call ثبت خلاصوي، input_digest(salt, inputs) == H_IN کتي، پروګرام په بېرته ترلاسه شویو ننوتو د امولېټر له لارې بیا چلوي، وتنې د رسید له وتنو سره پرتله کوي، او که هره یوه کتنه ناکامه شي له غیر صفر کوډ سره وځي، ترڅو یو سکرېپټ خبرداری د هو په توګه ونه ګڼي. --no-envelope بېرته نه اوړي: کله چې مالګه له منځه ولاړه شي، هېڅوک، حتی غوښتونکی هم، هغه غوښتنه نه شي خلاصولی.

له v0.6.8 راهیسې بیا چلول پر همغه عامه برخه کېږي چې ثبوت پرې جوړ شوی و: د پروګرام د ځای پر ځای کېدو د وخت عامې کلمې، او د hardening_v6 لاندې وروسته له هغو د غوښتنې اته کلمه ییز تړون (fullnode issue #116). په v0.6.7 کې open-call یوازې د هغه پروګرام لپاره کار کاوه چې پرته له عامې برخې ځای پر ځای شوی و. د هغه پروګرام لپاره چې عامه برخه یې درلوده، ننوتې یې چاپولې او بیا د re-running the program on these inputs failed: PublicIndex(0) سره درېده، او پرته له دې چې کومه کتنه وکړي، له غیر صفر کوډ سره وته.

د پروګرام حالت (RPL-2)

زنځیر 20 لومړنی زنځیر دی چې RPL-2 لري، چې د هغه د پیدایښت د program_state برخې له لارې فعالېږي. پروګرام درې شیان ترلاسه کوي چې مخکې یې نه درلودل (fullnode docs/program-state.md، crates/randprotocol-core/src/ledger/program_state.rs په v0.6.8 کې):

حجرې او د خزانې بیلانسونه عامه دي، لکه د یو توکن عرضه. په هغو کې هېڅ شی نوټ نه دی.

Invoke (Action 33) هغه غوښتنه ده چې یو انتقال هم اعلانوي، او د غوښتنې ثبوت یې ښيي چې پروګرام دقیقاً همغه انتقال مني:

Invoke     { program, proof, input_envelope, transition }
Transition { reads:  [{ key, value }]     // cells read, with the values read; keys strictly ascending
             writes: [{ key, value }]     // cells written; keys strictly ascending
             inflow: none | deposit | burn
             pays:   [{ asset, amount, recipient, r, envelope }]   // notes out of the vault
             mints:  [{ asset, amount, recipient, r, envelope }] } // new units of the program's own token

څه چې ننوځي هغه دي چې بنډل یې سوځوي: burn_r هغه RAND دی چې په خزانه کې زېرمه کېږي. د burn_asset څخه burn_a یو توکن دی چې زېرمه کېږي (د ننوتو ډول deposit) یا له منځه وړل کېږي (د ننوتو ډول burn، یوازې د پروګرام خپل توکن). څه چې وځي د هرې تادیې لپاره د زنځیر محاسبه شوی یو نوټ دی، لومړی تادیې بیا ضربونه، او مقدار او د ترلاسه کوونکي pk عامه وي، لکه د ضرب په څېر. دفتر انتقال یوازې هغه وخت پلي کوي چې پروګرام موجود وي، بڼه یې قانوني وي، په reads کې هره حجره لا هم اعلان شوی ارزښت ولري، خزانه (د همدې راکړې ورکړې له خپلې زېرمې وروسته) هره تادیه پوره کړي، هر ضرب د پروګرام د خپل توکن وي، او ثبوتونه تایید شي. هغه لوستنه چې نور سمون نه لري د StaleRead په توګه ردېږي. والټ بیا لولي او ثبوت بیا جوړوي.

اجرا غوښتنه له غوښتنې څخه څنګه توپیر لري.

پروګرام د شرایطو i کلمه له READ_PUBLIC(public_len + 8 + i) سره لولي. 0 کلمه نسخه ده (1)، له 1 تر 4 کلمې د لوستنو، لیکنو، تادیو او ضربونو شمېر دی، بیا burn_r، د ننوتو ډول، burn_asset او burn_a، بیا هره لوستنه او لیکنه د کیلي او ارزښت په توګه (هره یوه 8 کلمې)، بیا هره تادیه د شتمنۍ او مقدار په توګه. ترلاسه کوونکي په شرایطو کې نه دي: پروګرام مقدارونه ټاکي، او تړون ټاکي چې چا ته تادیه کېږي. پروګرام باید هره هغه د شرایطو کلمه محدوده کړي چې ورته ښودل کېږي، او باید هېڅ داسې لاره ونه لري چې panic ته ورسېږي، ځکه د guest-sdk panic سمبالوونکی اجرا دروي، او درول شوې اجرا هم د ثبوت وړ اجرا ده.

د زنځیر 20 حدونه (rand_getLimits.program_state):

د برخې قاعده معمولاً لا سخته وي: ټوله برخه باید په هغه عامه جدول کې ځای شي چې همغه پروګرام ته غوښتنه پرې ثابتېږي، یعنې د هغه پروګرام لپاره 127 کلمې چې عامه ننوته نه لري. دا 119 د شرایطو کلمې پرېږدي، د بېلګې په توګه درې لوستنې، درې لیکنې او څلور تادیې.

قوماندې او RPC (والټ v0.6.8):

rand program build --guest rpl2_counter --out counter.json   # one cell, incremented by one per invoke
rand program invoke <id> --transition step.json [--input N | --inputs-file F.json]
rand program state <id> [--cell <64 hex>]                   # rand_getProgramCell / rand_getProgramCells
rand program vault <id>                                      # rand_getProgramVault

program invoke د ثبوت له جوړولو مخکې هر reads ننوت له ژوندۍ حجرې سره پرتله کوي، او د زړې لوستنې په صورت کې، که د ثبوت له جوړولو مخکې وي یا د شاملېدو پر مهال، له 3 کوډ سره وځي، ترڅو سکرېپټ بیا ولولي او بیا هڅه وکړي. rand_estimateFee له "kind": "invoke" سره فیس اټکلوي. د انتقال د فایل بڼه د fullnode په docs/cli.md کې ده. په زنځیر 20 کې ځای پر ځای شوي بشپړ RPL-2 پروګرامونه (amm، stableswap، orderbook، stablecoin، lending، perp، crowdfund، stoploss) او RPL-1 پروګرامونه (sealed-auction، ballot، eligibility، private-join، credit-score) په randprotocol/example-programs کې دي.

څه عامه دي او څه پټ دي

د یوه اجرا دوه ثبوتونه بېلابېل بایټونه دي. دا په زنځیر 15 او تر هغه پخوا بس نه وو: هغې بلنې چې 31 یا لږې خصوصي کلمې یې درلودې داسې جدول ثابتاوه چې د پټولو لپاره ډېر کوچنی و، او ننوتنې یې له ثبوت څخه بېرته ترلاسه کېدای شوې. ثابتوونکي له v0.6 راهیسې دا جدولونه لږ تر لږه 128 قطارونو ته رسولي دي، او د محدودیتونو سېټ 7 (زنځیر 16 او وروسته) هغه د هر جدول ټولګې پټوي چې لا هم یې معلومات افشا کول. hc تړونکی دی خو پټوونکی نه دی: هر څوک چې د احتمالي پروګرامونو لړلیک جوړولای شي، تاییدولای شي چې کوم یو ځای پر ځای شوی.

څه چې لا ممکن نه دي

لکه څنګه چې یې fullnode بیانوي:

• د پروګرامونو ترمنځ بلنې نشته، او له RPL-2 بهر حالت نشته. یو Call د یوه اجرا پر سر یو ثبوت دی؛ له یوې بلنې څخه بلې ته هېڅ نه انتقالېږي پرته له هغه څه چې بلونکی یې بېرته ورکوي. په زنځیر 20 کې یو Invoke د پروګرام خپلې حجرې او خزانه لولي او لیکي (پورته)؛ له زنځیر 20 مخکې هېڅ زنځیر د پروګرام حالت نه لري، او یو invoke د بل پروګرام حجرو ته لاس نشي رسولای.
• له خزانې بهر د پروګرام په واسطه لېږدونه نشته. د اغېز ډول 1، چې پروګرام به یې یوه حساب ته لېږد تادیه کاوه، له حسابونو سره ړنګ شو، او د Call وتنې بیانونه دي. په زنځیر 20 کې یو Invoke د پروګرام له خپلې خزانې تادیه کوي، تر ډېره څلور نوټونه، چې مقدارونه او ترلاسه کوونکي یې عامه دي.
• په والټ کې کمپایلر نشته. پروګرامونه یا جوړ شوي اسمبل شوي ګیسټونه دي، یا هغه انځورونه چې د circuits په ذخیره کې د rand-guest په مرسته جوړ شوي وي.
• عامه ننوتنه د ځای پر ځای کولو پر مهال ټاکل کېږي، نه د هرې بلنې لپاره. د محدودیتونو سېټ 6 READ_PUBLIC او H_PUB زیات کړل. په زنځیر 20 کې یو ځای پر ځای کول تر 32,768 پورې عامه کلمې لېږدولای شي، د پروګرام id یې تړي، او د هرې بلنې ثبوت د هغوی د ډایجسټ پر وړاندې ازمویل کېږي. د هرې بلنې لپاره عامه کلمې نشته.
• د هش syscalls لوی ثبوتونه جوړوي. هغه ثبوت چې keccak لري شاوخوا 3.2 MB دی، چې په بشپړ ډول د ثبوت له 2 MiB ډیفالټ حد څخه اوړي؛ هغه ثبوت چې sha256 لري شاوخوا 400 KB زیاتوي. د زنځیر 20 حد 4,194,304 بایټه دی (4 MiB، لکه په زنځیرونو 17 تر 19؛ په زنځیرونو 13 تر 16 کې 8 MiB و)، چې دواړه مني: په زنځیر 18 کې د Keccak جدول سره د tier-12 بلنه 3.35 MB او د SHA-256 جدول سره د tier-14 بلنه 1.91 MB اندازه شوه (د بېلګې پروګرامونه). یوه بلنه همداراز تر 128 Keccak-f پرمیوټېشنونو او 128 SHA-256 کمپرېشنونو پورې محدوده ده (لاندې)، او د ثبوت هر KiB د بایټ په بیه حسابېږي.
• د EVM او Solana پروګرامونه په زنځیر 20 کې نه ځای پر ځای کېږي، او بلنې یې د بلنې د کچې له حد څخه اوړي. د مفسر ګیسټونه (evm.bin، 18,009 کلمې؛ sbpf.bin، 8,317) او ژباړل شوي انځورونه (ERC-20، 11,686 کلمې؛ SPL Token، 65,096) د 4,096 کلمو له ډیفالټ حد څخه اوړي او د هغه 65,535 حد لاندې دي چې زنځیر 13 ټاکلی او له هغه راهیسې هر زنځیر ساتلی دی. دواړه ژباړل شوي انځورونه په 2026-09-19 په زنځیر 13 کې ځای پر ځای شول، SPL Token د خپل ELF سره د عامه ننوتنې په توګه. زنځیرونه 14 او 15 له سره پیل شول، او په هېڅ یوه کې هېڅ انځور بیا ځای پر ځای نه شو. زنځیر 20، د زنځیر 19 په څېر، د دې څلورو هېڅ یو نه مني: د دې د hardening_v6 قاعدې له مخې هغه پروګرام چې هېڅ tier-14 بلنه یې نشي ځایولای، یعنې له 8,180 کلمو زیات کله چې عامه برخه ونه لري او لږ کله چې ولري، د ځای پر ځای کولو پر مهال ردېږي (ProgramUncallable)، څو د داسې پروګرام لپاره د ځای پر ځای کولو فیس ورنکړل شي چې هېڅوک یې نشي بللای. د ERC-20 بلنه په tier 16 یا 18 کې ثابتېږي: د tier-16 approve په 2026-09-19 په زنځیر 13 کې د 3,412,405 بایټه تولیدي ثبوت سره وبلل شو (Ethereum ژباړونکی)، او زنځیر 20 له tier 14 پورته هره بلنه ردوي (راتلونکی توکی)، نو نن هلته هېڅ ERC-20 بلنه د منلو وړ نه ده. د SPL Token بلنې tier 20 دي، چې شاوخوا 330 GB ته اړتیا لري؛ د SPL بلنې هېڅ ثبوت نشته (د ثبوت حافظه). د EVM د بلاک د شرایطو opcodes ودرېږي، او په زنځیر کې د EVM حالت نشته.
• یوه بلنه په tier 14 یا لاندې ثابتېږي. د fullnode له v0.5.6 (2026-09-25) راهیسې له tier 14 پورته د بلنې ثبوت ردېږي (CallTierTooHigh)، او همداراز هغه چې له 128 Keccak-f پرمیوټېشنونو یا 128 SHA-256 کمپرېشنونو زیات ولري. د زنځیر 13 د tier-16 ERC-20 approve به په زنځیر 20 کې رد شي، لکه څنګه چې به په زنځیرونو 15، 18 او 19 کې رد شوی وای، او همداراز به د tier-18 ERC-20 یا tier-20 SPL Token هره بلنه؛ دا لا هم له زنځیر بهر ثابتېږي (بودیجه).
• د GPU له لارې ثبوت جوړونه هېڅکله په هارډویر نه ده چلېدلې. --cuda د --features cuda جوړونې او کمیټ شوي PTX ته اړتیا لري؛ په fleet کې یو هم نشته. په زنځیر 20 کې د بلنې ثبوت د جوړونې په پام کې نیولو پرته د CPU په backend جوړېږي.
• hc پټوونکی نه دی، لکه څنګه چې پورته وویل شول، او د شاهد (witness) غوښتنه لا هم نوډ ته وايي چې والټ کومه پاڼه لګوي.