د Ethereum ټرانسپایلر

evm2rv د EVM د اجرا وخت bytecode، چې د solc --bin-runtime وتنه ده، اخلي او په یوه Rand پروګرام یې بدلوي. دا C لیکي، او rand-guest build دا C په یوه RV32IM انځور کې کمپایل کوي. انځور هماغه د ننوتو ویکتور اخلي چې د Rand د EVM مفسر مېلمه، evm.bin، یې اخلي، او هماغه اته د وتنې کلمې خپروي. دا قرارداد په اصلي ډول اجرا کوي، پر ځای د دې چې اوپکوډ په اوپکوډ یې تفسیر کړي. دا پاڼه ټوله لاره د یوه ERC-20 پر بېلګه ښيي.

دا څه شی دی

ژباړونکی د اجرا وخت کوډ اخلي، نه د جوړونې کوډ. یو ثبوت یوازې یو ځل غوښتنه پوښي چې یو ځای پر ځای شوي قرارداد ته کېږي، نو جوړوونکی (constructor) هېڅکله نه اجرا کېږي. هغه حالت چې جوړوونکي به لیکلی و، پر ځای یې د مخکیني حالت برخه ده، د ذخیرې د شاهدانو په توګه.

د ژباړې دوه پړاوونه دي. دواړه یو شان پایلې او ګاز ورکوي؛ هر یو یې ځانګړی پروګرام دی چې خپل hc لري.

د ننوتو ویکتور د مفسر ویکتور دی: کوډ، د غوښتنې ډېټا، غوښتونکی او د چاپېریال نورې کلمې، د ګاز حد، د مخکیني حالت ریښه، او د هر هغه سلاټ لپاره یو د ذخیرې شاهد چې غوښتنه ورته لاس رسوي. وتنې دا دي: out[0]، حالت (1 بریالیتوب، 0 بېرته ګرځول، 2 استثنايي درېدل)، او out[1..8]، د EVM_OUT ډایجسټ چې د کوډ هش، دواړه د حالت ریښې، بېرته راګرځېدلې ډېټا او لاګونه پوښي.

د باور ماډل

تاییدوونکی یو ژباړل شوی قرارداد په دوو ګامونو کې کتلی شي.

1. hc == translate(bytecode). evm2rv پر خپاره شوي bytecode بیا د هماغه --stage او --chain-id سره اجرا کړئ، د ټاکلو وسیلو سره یې بیا جوړ کړئ، او hc پرتله کړئ. تولید شوی crate cc دقیقاً ټاکي او خپل Cargo.lock لري.
2. د کوډ ساتونکی hc له bytecode سره تړي. ژباړل شوې منطق په انځور کې کمپایل کېږي، خو CODECOPY او CODESIZE هغه کوډ لولي چې د ننوتو په ویکتور کې دی. له کتنې پرته، یو hc کېدای شي د هغو کوډ بایټونو سره اجرا شي چې غوښتونکي ټاکلي وي. نو contract.c د سرچینې bytecode (د هغه اوږدوالی او بایټونه) یو Poseidon2 ډایجسټ لري، او شیم د ننوتو د ویکتور کوډ په هماغه ډول هش کوي مخکې له دې چې هر ژباړل شوی کوډ اجرا شي. بل کوډ ردېږي: حالت 2، gas_used 0، درېدل OutOfBounds.

د EVM_OUT ډایجسټ د کوډ keccak256 هم تړي، لکه څنګه چې د مفسر ډایجسټ یې تړي. ځنځیر د سرچینې bytecode یا د هغه هش نه ثبتوي. د دې لپاره چې نور hc وکتلی شي، bytecode خپور کړئ، یا د Solidity سرچینه او د solc دقیق جوړښت.

ساتونکی پر لېږد 1,008 سایکلونه لګوي. هغه کوډ چې له سرچینې سره یو بایټ توپیر ولري، په دویم پړاو کې په 30,418 سایکلونو کې ردېږي (کچه 16).

پوښښ، او څه ټریپ کوي

اوپکوډونه. د Shanghai ټولګه. د --evm-version shanghai سره کمپایل کړئ: نوي هدفونه MCOPY او د Cancun نور اوپکوډونه تولیدوي، چې ټریپ کوي.

د چاپېریال اوپکوډونه:

د بلاک د شرایطو نهه اوپکوډونه تر هغه ټریپ کوي چې یو بلاک ته د هغوی د تړلو لپاره ډیزاین جوړ شي. یو خصوصي ننوت د بلاک واقعیت نشي لېږدولی، ځکه چې تاییدوونکی H_IN نشي خلاصولی. تر هغه چې دا پرېکړه وشي، هغه قرارداد چې وخت یا د بلاک شمېره لولي (د بېلګې په توګه د permit وروستۍ نېټه) ټریپ کوي.

غوښتنې. CALL، CALLCODE، DELEGATECALL او STATICCALL یو precompile اجرا کوي کله چې هدف له 1 تر 9 پته وي. هر بل هدف ټریپ کوي. پر CALL یا CALLCODE له صفر پرته ارزښت ټریپ کوي: د بیلانس ماډل نشته.

Precompiles. ټول نهه په سافټویر کې اجرا کېږي. ځینې یې نن د ثبوت لپاره ډېر ورو دي، ځکه چې یو ثبوت تر ټولو ډېر 2²⁰ قطارونه لري:

د modexp بنسټ او ماډولس هر یو تر 1,024 بایټو پورې محدود دي.

منل شوي توپیرونه. حالت، اته کلمې او gas_used باید سمون ولري. درې توپیرونه منل شوي دي: د درېدو ډول کېدای شي توپیر ولري (ثابت ګاز د هر بلاک په سر کې اخیستل کېږي، نو OutOfGas او بل درېدل کېدای شي ځایونه بدل کړي؛ دواړه حالت 2 دي او ټول ګاز پکې مصرفېږي)؛ ژباړه CHAINID، ORIGIN او د precompile غوښتنې پلي کوي، چې مفسر یې ټریپ کوي؛ او د کوډ ساتونکی د خپلې سرچینې پرته بل کوډ ردوي.

شمېرې

د ERC-20 غوښتنې، د کوډ ساتونکي سره. سایکلونه له rand-guest run څخه؛ کچه په قوسونو کې.

دویم پړاو درې غوښتنې د مفسر د سایکلونو په 54.5%، 56.2% او 55.0% کې اجرا کوي. لېږد په 18 کچه کې پاتې کېږي: د هغه 66,235 سایکلونه جمع 3,155 د ډایجسټ قطارونه 69,390 قطارونه کېږي، چې د 16 کچې له 65,535 څخه 3,855 ډېر دي.

د دویم پړاو د یوه لېږد نږدې 60% (نږدې 39,928 سایکلونه) هغه چوکاټ دی چې دواړه انځورونه یې شریکوي: د ننوت ډیکوډ کول، د ذخیرې د شاهدانو تایید، د ABI د keccak256 غوښتنې او د وتنې ډایجسټ. د ژباړې هېڅ کار له دې کچې ښکته نشي تللی.

ګام په ګام: یو ERC-20، له Solidity څخه تر سمون لرونکو وتنو پورې

هر کمانډ د circuits د یوې checkout له ریښې څخه په 7ef3220 کې اجرا کېږي، د یو Rust پروګرام ځای پر ځای کړئ له وسیلو او د یو RISC-V پروګرام ځای پر ځای کړئ له clang 23.1.1 سره. اوږده وتنه هلته لنډه شوې چې په … نښه شوې ده.

0. وسیلې جوړې کړئ

(cd evm2rv && cargo +1.98.1 build --release)
(cd rand-guest && cargo +1.98.1 build --release)

1. Solidity د اجرا وخت په bytecode کمپایل کړئ

قرارداد هماغه ثبت شوی guests-compiled/evm/contracts/ERC20.sol دی: یو بشپړ خپلواک ERC-20 د OpenZeppelin v4 د ذخیرې ترتیب سره، pragma solidity 0.8.37. دقیقاً solc 0.8.37 وکاروئ؛ بله نسخه په بل ډول اصلاح کوي او بل bytecode ورکوي.

$ curl -sSL -o solc https://github.com/ethereum/solidity/releases/download/v0.8.37/solc-macos
$ shasum -a 256 solc
a27396e7732aa52e80ff89ad7bd8a2e46fec2a6dcc4ef20cd16e5e0c502d6821  solc
$ chmod +x solc && ./solc --version
solc, the solidity compiler commandline interface
Version: 0.8.37+commit.f401782d.Darwin.appleclang

$ (cd guests-compiled/evm && ../../solc --optimize --optimize-runs 200 --evm-version shanghai \
      --bin-runtime contracts/ERC20.sol) | tee solc.out
======= contracts/ERC20.sol:ERC20 =======
Binary of the runtime part:
608060405234801561000f575f5ffd5b5060043610610060575f3560e01c8063095ea7b31461006457806318160ddd1461008c57806323b872dd1461…
$ tail -1 solc.out > evm2rv/target/mytoken.hex

وروستۍ کرښه د اجرا وخت bytecode دی، 1,296 بایټه. دا له ثبت شوي guests-compiled/evm/contracts/erc20.runtime.hex سره بایټ په بایټ یو شان دی؛ SOLC=$PWD/solc bash guests-compiled/evm/contracts/build.sh دا کتنه کوي او contracts: erc20.runtime.hex reproduces چاپوي.

بیرغونه مهم دي:

• --bin-runtime: ځای پر ځای شوی کوډ، نه د جوړونې کوډ.
• --evm-version shanghai: د 0.8.37 ډیفالټ هدف MCOPY تولیدوي، چې ټریپ کوي.
• --optimize --optimize-runs 200: د ځای پر ځای شوي قرارداد پروفایل.

2. وژباړئ

$ evm2rv/target/release/evm2rv evm2rv/target/mytoken.hex --out evm2rv/target/mytoken --chain-id 12
1296 code bytes: 74 blocks, 798 opcodes, 51 jumpdests (stage 2)
CHAINID is the constant 12
no trapping opcodes present
wrote evm2rv/target/mytoken (crate mytoken): contract.c, Cargo.toml, Cargo.lock, build.rs, src/main.rs, shim.ld

• --out باید د circuits د یوې checkout دننه وي. له هغه پرته، evm2rv یوازې کوډ تحلیلوي.
• هر ټریپ کوونکی اوپکوډ به دلته د خبرتیا په توګه، د خپل pc سره، لیست شي.
• دا ناسته د --chain-id 12 سره ثبت شوې وه. دا ERC-20 CHAINID نه لري، نو --chain-id د هغه hc نه بدلوي. هغه قرارداد چې CHAINID لولي، دا بیرغ ته اړتیا لري؛ هغه ځنځیر ته یې وټاکئ چې پر هغه به ځای پر ځای کېږي (--chain-id 19 د ژوندي ځنځیر لپاره).

contract.c د کوډ ساتونکي په ډایجسټ پای ته رسېږي:

const uint32_t *evm_code_digest(void) {
    static const uint32_t d[8] = {0xf679280fu, 0x86c10e83u, 0x7e8f1f39u, 0xa2377de3u, 0x8a2e282fu, 0xc54cad42u, 0xddfaf009u, 0x7d28a8afu};
    return d;
}

3. انځور جوړ کړئ

ډیفالټ حد 4,096 کلمې دی، نو --max-words 65535 ورکړئ.

$ rand-guest/target/release/rand-guest build evm2rv/target/mytoken --max-words 65535
…
11686 words against a cap of 65535 (fits); 0 ecall(s) with a non-static a7
OK
wrote evm2rv/target/mytoken/image.bin and its .sha256 (11686 words, hc a0feae92a7311c9562495717100eb7aea71270a38ed435d06dc31387e0ea8ff6, program id f074c4eb834cf01886a8241b6a2e0caf6e1cee5327fee6cb1a1a37436607280d)

$ rand-guest/target/release/rand-guest info evm2rv/target/mytoken/image.bin
form: image container
text 11147 words at 0x10000; data 408 words (205 non-zero) at 0x1ae2c; prologue 539 words; program 11686 words from base_pc 0xf794
hc a0feae92a7311c9562495717100eb7aea71270a38ed435d06dc31387e0ea8ff6
program id f074c4eb834cf01886a8241b6a2e0caf6e1cee5327fee6cb1a1a37436607280d
11686 words against a cap of 4096: does not fit

دا هماغه خپور شوی د دویم پړاو hc دی. د crate نوم پر هغه اغېز نه کوي.

4. د ننوتو یو ویکتور جوړ کړئ او یو لېږد اجرا کړئ

د erc20_vector بېلګه د سمون ازموینې ویکتورونه د ننوتو د کلمو په توګه چاپوي: transfer (ALICE له خپلو 1,000 څخه BOB ته 250 لېږي)، approve (ALICE BOB ته اجازه ورکوي چې 5 مصرف کړي) او transferFrom (BOB د 300 د اجازې پر وړاندې د ALICE له 1,000 څخه 100 لېږدوي). د خپل قرارداد لپاره، په Rust کې په هماغه ډول یو EvmCall جوړ کړئ؛ بېلګه یې نمونه ده.

$ (cd evm2rv && cargo +1.98.1 run -q --release --example erc20_vector -- transfer > target/transfer.words)
921 input words

$ rand-guest/target/release/rand-guest run evm2rv/target/mytoken/image.bin --input $(cat evm2rv/target/transfer.words)
out[0] = 1
out[1] = 513227413
out[2] = 3087537901
out[3] = 995619457
out[4] = 4004100029
out[5] = 234390638
out[6] = 3262201797
out[7] = 3842361427
cycles 66235
tier 18

5. له مفسر سره یې پرتله کړئ

هماغه ننوت د مفسر پر مېلمه:

$ rand-guest/target/release/rand-guest run guests-compiled/bin/evm.bin --input $(cat evm2rv/target/transfer.words)
out[0] = 1
out[1] = 513227413
out[2] = 3087537901
out[3] = 995619457
out[4] = 4004100029
out[5] = 234390638
out[6] = 3262201797
out[7] = 3842361427
cycles 121638
tier 18

او مفسر په کوربه سیستم کې په اصلي ډول چلېږي، چې د ازموینو oracle دی:

$ (cd evm2rv && cargo +1.98.1 run -q --release --example erc20_vector -- transfer --expected)
out[0] = 1
out[1] = 513227413
…
out[7] = 3842361427
interpreter (native): status 1, Return, gas_used 29956

دا ارزونه د یوه امر په توګه:

$ diff <(rand-guest/target/release/rand-guest run evm2rv/target/mytoken/image.bin --input $(cat evm2rv/target/transfer.words) | grep '^out') \
       <(rand-guest/target/release/rand-guest run guests-compiled/bin/evm.bin --input $(cat evm2rv/target/transfer.words) | grep '^out') \
  && echo "the eight words are identical"
the eight words are identical

څلورم او پنځم ګامونه له approve او transferFrom سره تکرار کړئ؛ دواړه ورته کلمې ورکوي. cd evm2rv && cargo +1.98.1 test --release دا او پنځه نور وکتورونه د دواړو پړاوونو لاندې چلوي، او gas_used هم ارزوي (70 ازموینې، او 2 له پامه غورځول شوي ثبوتونه).

6. ځای پر ځای کول

rand program deploy evm2rv/target/mytoken/image.bin

والټ د پروګرام id، د کلمو شمېر او hc چاپوي، بیا مخکې له دې چې څه ثابت کړي، د چین حد ارزوي. انځور 11,686 کلمې دی، نو داسې چین ته اړتیا لري چې جېنیسس یې max_program_words لږ تر لږه 11,686 ته ټاکلی وي. چین 12 د 4,096 ډیفالټ کاراوه، نو هلته ځای پر ځای کول رد شول. چین 13، د v0.4 چین، max_program_words په 65,535 ټاکلی و، او له هغه وروسته هر چین دا ارزښت ساتي. چین 20، ژوندی چین (جېنیسس 6210cf071a390d7ac61d8cbea5dd9d139d1a493a862b54a45a498f36af2d5135)، د چین 13 د بلاک، د غوښتنې د پاکټ او د عامه ننوتو حدونه هم ساتي او د ثبوت حد نیمايي کوي تر 4 MiB (4,194,304 بایټه، له چین 17 راهیسې؛ چینونو 13 تر 16 پورې 8 MiB ټاکلي و). د کلمو حد نور یوازینی دروازه نه ده. د چین 20 جېنیسس hardening_v6 ټاکي، او د هغه لاندې د داسې پروګرام ځای پر ځای کول چې کلمې یې د پوړ-14 د غوښتنې په حد کې د یوې غوښتنې له ظرفیت څخه زیاتې وي، ناسم دی (ProgramUncallable): پرته له عامه ننوتو، تر ټولو ډېر 8,180 کلمې. دا انځور 11,686 کلمې دی، نو چین 20 یې ځای پر ځای کول ردوي، او غوښتنې به یې هم رد کړي: د ERC-20 هره غوښتنه په 16 یا 18 پوړ ثابتېږي، چې د پوړ-14 د غوښتنې له حد څخه پورته دي (اووم ګام). په چین 20 د بلاکونو راټولول بند دي (د هغه جېنیسس د aggregation برخه نه لري)؛ د هغه د بوټسټرپ نوډونه په د اعتباروونکي چلول کې لېست شوي دي. د ځای پر ځای کولو فیس 0.001 + 0.0001 × 11,686 = 1.1696 RAND دی، هغه فیس چې لاندې د چین 13 ځای پر ځای کولو ورکړی.

دا ځای پر ځای کول د 2026-09-19 په نېټه په چین 13 ترسره شول، کله چې چین 13 ژوندی چین و (د FRI تولیدي پروفایل، جېنیسس 8123ccac1883a45750e4df6964fb7cd3f0b321798cde4c0ef406a0293939ece3)، د جېنیسس له والټ shielded-1 څخه. له هغه وروسته هر چین (14 تر 19 پورې) د یوه نوي چین په توګه پرته د چین 13 له پروګرامونو جوړ شو، او انځور په هېڅ یوه کې بیا نه دی ځای پر ځای شوی، نو لاندې راکړه ورکړه او لوړوالی د چین 13 دي او نور په explorer کې نه موندل کېږي. د پروګرام id یوازې د base_pc او کلمو hash دی، نو ورته انځور په هر هغه چین کې چې ځای پر ځای کول ومني ورته id ترلاسه کوي. د والټ وتنه، چې د پرمختګ کرښې یې لنډې شوې دي (…):

$ rand program deploy <image.bin>
program id: f074c4eb834cf01886a8241b6a2e0caf6e1cee5327fee6cb1a1a37436607280d (11686 words, hc 92aefea0951c31a717574962aeb70e10a37012a7d035d48e8713c36df68feae0)
…
proved in 92.2s: tier 14, 1419655 bytes
submitted deploy c7a66dc4d9cdb7f9bfc4bde01f618c356e5abad7097e6bf7dc04e2e49c53acd0
…

له چین 14 راهیسې ورکوونکی بنډل هغه یو 4-ننوتو-4-وتو پټ-شتمنۍ بنډل دی چې هره راکړه ورکړه یې لېږدوي، او د راکړې ورکړې د تړنې په وړاندې ثابتېږي. دا لا هم پوړ 14 دی: د چین 14 او 15 په تولیدي پروفایل کې شاوخوا 100 s او شاوخوا 1.42 MB. له چین 17 راهیسې یو بنډل د پوړ-10 د اجازې ثبوت هم لېږدوي (وېشل شوې اجازه)، نو په چین 18 او 19 کې د یوې راکړې ورکړې د فیس بنډل شاوخوا 1.49 MB د بنډل ثبوت او شاوخوا 1.37 MB د اجازې ثبوت دی.

7. غوښتنه

د لېږد غوښتنه 921-کلمه‌ییز وکتور د خصوصي ننوتو په توګه لېږدوي، په هر چین کې د ننوتو تر حد لاندې (په ډیفالټ ډول 4,295 کلمې، په چین 20 کې 16,071)، او هېڅ عامه کلمې نه لري. دا چین 20 ته نه شي سپارل کېدای: پروګرام هلته نه شي ځای پر ځای کېدای (شپږم ګام)، لېږد په 18 پوړ ثابتېږي، او له fullnode v0.5.6 (2026-09-25) راهیسې یو نوډ د پوړ 14 څخه پورته هر د غوښتنې ثبوت د CallTierTooHigh سره ردوي، مخکې له دې چې د تصدیق کیلي جوړه کړي. لاندې امر په محلي ډول ثبوت جوړوي او چین پایله ردوي؛ اندازه‌ګیرنې د چین څخه بهر ثبوتونه دي. rand call هره کلمه د تکرار شوي --input په توګه اخلي:

rand call f074c4eb834cf01886a8241b6a2e0caf6e1cee5327fee6cb1a1a37436607280d \
    $(for w in $(cat evm2rv/target/transfer.words); do printf -- '--input %s ' "$w"; done)

اوس اندازه شوی. د پوړ-18 یو ثبوت په 48 GB لپټاپ کې په 24.7 GB کې ودرول شو، خو په 128 GB ډراپلېټ (m-16vcpu-128gb) کې ژباړل شوې transfer غوښتنه ثابته شوه: د RSS لوړه کچه 85.0 GB، 3,230.5 s (53.8 min)، او 811,600-بایټه ثبوت. دا په ډراپلېټ کې په 101.4 s کې تصدیق شو او په 48 GB Apple-silicon لپټاپ کې په 50.2 s کې په 3.66 GB RSS (د ثبوت جوړونې حافظه). د لیجر د پوړونو د مساوي مهالوېش لاندې، چې د هغو چینونو قاعده ده چې د gas برخه نه لري (تر چین 17 پورې)، په 18 پوړ کې د غوښتنې فیس 0.0024 RAND و. چینونه 18 او 19 د دې پر ځای غوښتنه د هغې د اعلان شوي ګاز حد او بایټونو له مخې بیه کوي، د جېنیسس په بیو کې د هر ګاز لپاره 100 واحده او د هر KiB لپاره 800، او د پوړ 14 څخه پورته هېڅ غوښتنه نه مني.

په چین 13 کې غوښتنه، 2026-09-19

د approve(BOB, 5) غوښتنه (649 خصوصي کلمې، پوړ 16) د 2026-09-19 په نېټه په چین 13 ترسره شوه، کله چې هغه ژوندی چین و، د FRI تولیدي پروفایل، له ورته والټ څخه. په هېڅ وروستي چین کې، چې پروګرام پکې ځای پر ځای شوی نه دی، غوښتنه نه ده شوې، او چین 20 دا د پوړ-16 د غوښتنې ثبوت ردوي (CallTierTooHigh). د والټ وتنه، چې د پرمختګ کرښې یې لنډې شوې دي (…):

$ rand call f074c4eb834cf01886a8241b6a2e0caf6e1cee5327fee6cb1a1a37436607280d --input <w0> --input <w1> …   # the 649 words of approve(BOB, 5)
…
proved in 388.7s: tier 16, 3412405 bytes, outputs [1, 942495465, 790002515, 1351749335, 1059083501, 2923046783, 2814575942, 696258848]
…
proved in 96.0s: tier 14, 1420423 bytes
submitted call 279e1f62abf3f177ca71b08c633e051c37bc4720118c79ddb00936f036c4bfa7
…

• تولیدي ثبوت 3,412,405 بایټه دی، چې د چین 12 د 2 MiB د ثبوت له حد څخه زیات دی. چین 12 دا غوښتنه نه شوه منلای؛ د چین 13 د 8 MiB حد ومنله. چینونو 14 تر 16 پورې ورته حد وساته، او چینونو 17 تر 20 پورې 4 MiB (4,194,304 بایټه) وټاکه، چې د دې اندازې ثبوت لا هم ترې لاندې ځای نیسي. له v0.5.6 راهیسې یو نوډ غوښتنه د هغې د پوړ له امله ردوي، مخکې له دې چې اندازې ته یې وګوري.
• فیس د چین 13 د مهالوېش د بایټ برخه لري: د 3.41 MB ثبوت د 2 MiB + 18,432-بایټه وړیا اجازې څخه پورته دی. له چین 18 راهیسې هره غوښتنه له لومړي بایټ څخه د هر KiB لپاره ورکړه کوي.

د رسید اته کلمې هماغه دي چې په څلورم ګام کې دي. چین د EVM حالت نه ساتي: غوښتونکی د مخکیني حالت ریښه او د ذخیرې شاهدان برابروي، او د وروستي حالت ریښه د EVM_OUT digest دننه ده.

محدودیتونه

• د بلاک شرایط نشته. د بلاک شرایطو نهه واړه اپ‌کوډونه تر هغه ودرېږي چې د بلاک د تړلو ډیزاین موجود نه شي.
• د ارزښت لېږد نشته. هغه CALL چې ارزښت یې له صفر پرته وي ودرېږي. له مخکې ترتیب شویو قراردادونو پرته نورو قراردادونو ته غوښتنې ودرېږي.
• ecrecover، د bn256 ضرب، جوړه کول (pairing) او لوی modexp نن ورځ نشي ثابتېدای. هر یو یې د 2²⁰ کرښو د طبقې له حد څخه اوړي؛ دوی د همپروسسر جدولونو ته اړتیا لري.
• په chain کې د EVM حالت نشته. هره غوښتنه د یوې اجرا پر سر یو ثبوت دی؛ حالت غوښتونکی له ځان سره وړي.
• په chain 20 کې نه deploy منل کېږي او نه د ERC-20 کومه غوښتنه. د chain 20 د hardening_v6 له مخې هغه deploy چې له هغو کلمو ډېرې ولري چې د tier-14 یوه غوښتنه یې ساتلای شي ناسم دی (ProgramUncallable؛ تر ټولو ډېر 8,180 کلمې)، او انځور 11,686 کلمې دی. د fullnode v0.5.6 راهیسې د غوښتنې ثبوت باید په tier 14 یا تر هغې ټیټه طبقه کې وي (CallTierTooHigh)؛ approve په tier 16 کې ثابتېږي، transfer او transferFrom په tier 18 کې. همدا معاینه هغه هش جدولونه هم محدودوي چې یوه غوښتنه یې اعلانولای شي: د Keccak 2¹² کرښې (128 پرمیوټېشنونه) او د SHA-256 2¹³ کرښې (128 فشارونه). غوښتنې لا هم له chain بهر ثابتېږي، لکه څنګه چې لاندې راغلي.
• د ذخیرې شاخص 32 بټه ژور دی. evm-core د قرارداد د ذخیرې پاڼه د keccak256(slot) د پورتنیو 32 بټونو له مخې ځای پر ځای کوي، نو د هغه سلاټ موندل چې له یوه ټاکل شوي سلاټ سره ټکر وکړي شاوخوا 2³² Keccak هشونه لګښت لري، او تر هغه چې هغه له صفر پرته ارزښت ولري، ټاکل شوی سلاټ کنګل پاتې کېږي (نه جعل کېږي او نه ارزښت ورکېږي). دا ستونزه اوس غیرفعاله ده: evm.bin 18,009 کلمې دی، او د tier-14 په حد کې یوه غوښتنه تر ټولو ډېر 8,184 کلمې ساتلای شي، نو هېڅ EVM runtime په هېڅ chain کې د غوښتنې وړ نه دی. د fullnode docs/confidential.md دا مخکینی شرط د غوښتنې د حد تر څنګ ثبتوي (audit v6، ZKV-6؛ له 2026-09-30 راهیسې په main کې، د v0.6.7 tag وروسته): مخکې له دې چې یو chain د tier-14 د غوښتنې حد لرې کړي یا داسې EVM runtime ومني چې د غوښتنې لپاره کافي کوچنی وي، د ذخیرې شاخص باید ژور شي او evm.bin بیا pin شي.
• ثابت شوی. د لومړي پړاو د لېږد ثبوت (tier 18) په یوه 48 GB لپ‌ټاپ کې له 1,016 s وروسته په 24.7 GB کې د SIGKILL له لارې ووژل شو، خو د دویم پړاو transfer غوښتنه په یوه 128 GB droplet (m-16vcpu-128gb) کې ثابته شوه: 85.0 GB د RSS لوړه کچه، 3,230.5 s (53.8 min)، یو 811,600 بایټه ثبوت، چې په 101.4 s (droplet) کې او په 50.2 s کې په 3.66 GB RSS سره (48 GB لپ‌ټاپ) تایید شو. د تفسیرونکي evm.bin د لېږد ثبوت ورسره ډېر نږدې سمون درلود: 85.5 GB، 3,143.3 s (52.4 min)، یو 805,108 بایټه ثبوت — او دواړه ثبوتونه یو شان عامې وتونکې کلمې لري، چې په ریښتیني ثابتوونکي کې برابري تاییدوي. approve (tier 16، ژباړل شوی) ډېر ارزانه دی: 21.7 GB، 786.7 s (13.1 min)، یو 798,930 بایټه ثبوت. ژباړه یوازې هغه وخت د ثبوت لګښت کموي چې یوه غوښتنه کوچنۍ طبقې ته راښکته کړي.
• chain بایټ‌کوډ نه ثبتوي. هغه خپور کړئ ترڅو نور وکولای شي hc بیا جوړ کړي.