Bukti

Gunakan halaman ini untuk menentukan ukuran mesin pembuktian, untuk memahami mengapa sebuah transfer memerlukan waktu lebih dari satu menit dan mengapa ruang blok, bukan komputasi, yang membatasi throughput, serta untuk mengetahui apa yang rusak ketika sistem bukti berubah. Segala sesuatu yang diterima validator didukung oleh bukti yang telah diverifikasinya sendiri.

Apa yang dinyatakan sebuah bukti

Satu relasi, untuk setiap program yang dijalankan chain:

Program RV32IM ini, dimulai pada base_pc, dijalankan pada vektor input privat yang dikomit oleh H_IN dan segmen input publik yang dikomit oleh H_PUB, berhenti dalam 2ᵗ − 1 siklus, menghabiskan paling banyak GAS_LIMIT gas, dan menerbitkan delapan word keluaran ini.

Program diidentifikasi oleh digest dalam sirkuitnya, hc; verifier tidak pernah melihat satu pun word instruksi. Sebuah transfer terlindung adalah relasi tersebut yang diterapkan pada guest bundel aset tersembunyi, program 4-input-4-output yang dirakit tangan dan hc-nya dipatok dalam file genesis sebagai hc_bundle. Chain 20 mematok guest v3 (guests::bundle_hidden_v3, 60af094a…6e3fce, sejak chain 17). Chain 14 dan 15 mematok v1 (83d3a370…cd0ef8) dan chain 16 mematok v2 tanpa percabangan (651043e2…839b). Sejak chain 17 setiap bundel juga membawa bukti kedua, yaitu guest auth (guests::auth, genesis hc_auth, 1e4e347f…5639c1): bukti bundel menerima viewing key, dan bukti auth menunjukkan bahwa pengirim memegang spend key di baliknya. Ini adalah otorisasi terpisah, dan inilah yang memungkinkan prover berpasangan yang hanya memegang viewing key membuat bukti bundel. Guest aset tersembunyi menggantikan guest bundle 2-input-2-output pada chain hingga 13, yang hanya tersisa di fullnode untuk pengujian dan tidak dipatok oleh chain mana pun. Sebuah panggilan rahasia adalah relasi yang sama yang diterapkan pada program yang telah di-deploy (Programs).

Bagaimana wallet membuktikan sebuah bundel

rand send <rand1…> <amount> mengerjakan pekerjaan privat secara lokal, dan hanya bukti, komitmen, nullifier, dan envelope tersegel yang sampai ke chain:

1. Pindai pohon dengan viewing key dan pilih input: paling banyak dua note RAND yang mencakup jumlah ditambah biaya pada slot 2–3, dan untuk transfer atau burn token paling banyak dua note token pada slot 0–1 dengan note RAND yang hanya mencakup biaya. Slot input yang tidak terpakai adalah dummy: jumlah 0, dimiliki oleh wallet, kegagalan keanggotaannya ditutupi dalam sirkuit, nullifier tetap diterbitkan. Sejak guest v2 guest tersebut tanpa percabangan: path dummy di-hash sepanjang 32 level seperti pada note asli.
2. Ambil anchor kepala (rand_getAnchor) dan saksi Merkle 32 level dari setiap input asli (rand_getWitness(index)), dengan memeriksa root yang dikembalikan terhadap anchor.
3. Susun empat output: note penerima dan note kembalian pada kelompok yang memindahkan nilai, tetap ada walaupun bernilai nol, serta dummy bernilai nol di tempat lain, disegel ke kunci sekali pakai.
4. Segel setiap output dalam sebuah envelope (ML-KEM-768 untuk penerima, ditambah kunci transaksi yang dibungkus di bawah ovk wallet), rakit seluruh transaksi beserta action-nya, dan ambil binding-nya: blake3("rand-tx-bind-1" || …) atas transaksi dengan bukti dikosongkan, delapan word (Transactions). Pada chain 20, yang genesis-nya menetapkan binding_domain: 1, binding-nya adalah blake3("rand-tx-bind-2" || …) dengan hash genesis di urutan pertama, lalu chain id, sehingga bukti yang dibuat untuk satu chain tidak terverifikasi di chain lain mana pun, bahkan yang memiliki chain id yang sama. Wallet yang lebih lama dari v0.6.8 memakai binding lama, dan chain 20 menolak buktinya.
5. Otorisasi: ambil salt 256-bit yang baru dan buktikan guest auth pada input privat 16 word-nya, yaitu spend key dan salt, dengan binding sebagai segmen input publik, pada tier 10. Guest ini menurunkan nk dari spend key dan menerbitkan c = H(AUTH, nk ‖ salt), yang dibawa bundel sebagai auth_commit.
6. Buktikan guest bundel pada input privat 1.212 word-nya (viewing key nk, empat slot input beserta path-nya, anchor, empat output, fee, burn_a, burn_r, aset privat A, time, salt) dengan binding yang sama sebagai segmen input publik, pada tier 14. Bukti ini menunjukkan kepemilikan, keanggotaan, bahwa setiap input asli membawa aset slot-nya, keempat nullifier, c yang sama, dan kedua keseimbangan in₀ + in₁ = out₀ + out₁ + burn_a dan in₂ + in₃ = out₂ + out₃ + fee + burn_r. Inilah bukti yang dapat dibuat prover berpasangan sebagai pengganti wallet; bukti auth dibuat di mesin wallet itu sendiri.
7. Periksa digest yang diterbitkan bukti terhadap digest yang dihitung dari plaintext, lalu kirim Transaction { chain_id, bundle, action: None }.

Urutannya penting sejak chain 14: envelope dan action sudah ada sebelum bukti, karena bukti mengomit keduanya. Untuk sebuah panggilan, bukti panggilan dibuat lebih dahulu dan juga berada di dalam binding. Pada chain hardening_v6, bukti panggilan itu sendiri dibuat atas binding panggilan dari transaksi dengan kedua bukti dikosongkan (rand-call-bind-1 pada chain 16 hingga 19, rand-call-bind-2 dengan hash genesis pada chain 20), yang mencakup nullifier bundel biaya, sehingga bukti tersebut tidak dapat disalin ke bundel lain.

proving bundle (tier 14; about a minute on a laptop)…
proved in 98.3s: tier 14, 1423170 bytes
submitted transfer 4f2c…  1.5 RAND out, 98.499 RAND change, fee 0.001 RAND, anchored at height 192

Transkrip tersebut adalah format keluaran wallet dari panduan fullnode per chain 14; jumlah byte yang ditampilkan adalah milik bukti bundel profil produksi yang dikomit pada chain 14. Wallet sejak chain 17, termasuk v0.6.8 pada chain 20, mencetak dua baris sebelum baris-baris ini, proving the spend authorisation on this machine (tier 10; seconds)… dan authorisation proved in …: tier 10, … bytes, serta menyusun baris bundel sebagai proving the bundle (tier 14; about a minute and a half on a laptop)….

Mesin yang sama membayar setiap action, selalu dengan tepat satu bundel: sebuah deploy, panggilan, pendaftaran token, atau pencetakan token ditumpangkan pada transfer mandiri RAND bernilai nol, sebuah bond pada bundel yang membakar stake melalui burn_r, dan burn token atau burn bridge pada satu bundel yang membakar aset dari slot 0–1 (burn_a, burn_asset) dan membayar biaya RAND dari slot 2–3. Aset yang dipindahkan sebuah transfer adalah word saksi dan tidak ada di bidang publik mana pun.

Berapa biayanya

Diukur pada laptop pengembangan (Apple Silicon, build rilis), angka-angka yang dicatat dokumen fullnode sendiri:

Verifikasi adalah biaya konsensus, yang dibayar oleh setiap node: sekitar 16 ms dengan verifier key yang hangat, sekitar 230 ms pada saat pertama sebuah key dibangun untuk bentuk tertentu. Verifier key tidak bergantung pada isi program — key ini dikunci pada (tier, program_log_height, input_log_height, keccak_log_height, sha256_log_height, public_log_height) — sehingga sebuah node membangun satu key per bentuk dan memakainya kembali; untuk program yang di-deploy, key dihitung sekali di latar belakang pada saat deploy (sekitar 2 dtk pada laptop, 7 dtk pada server 2-vCPU). Bundel 2-input-2-output pada chain 13 dan sebelumnya menyatakan bentuk program 12, input 10, keccak 0, sha256 0, public 2, mem 16; bukti bundel chain 14 menyatakan public 4, tinggi dari delapan word binding, tidak membawa tabel hash apa pun, dan ditolak sebelum verifier key apa pun dibangun jika menyatakan tier lain, tabel apa pun, atau tinggi publik lain. Sejak constraint set 7 setiap tabel yang dinyatakan memiliki setidaknya 2⁷ baris, sehingga bukti bundel chain 20 menyatakan public 7.

Sebuah transfer pada chain 20 dengan demikian membawa sekitar 2,87 MB bukti, yaitu bundle proof dan auth proof, dan sebuah call membawa bukti ketiga di atasnya. Masing-masing harus muat dalam max_proof_bytes genesis, yaitu 4.194.304 (4 MiB) pada chain 20, sama seperti pada chain 17 sampai 19, turun dari 8 MiB pada chain 13 sampai 16.

Guest aset tersembunyi hanya muat pada tier 14 karena guest tersebut membaca input privatnya dalam sebuah loop dan menggabungkan pembacaan sibling pada pemeriksaan Merkle; bila ditulis dengan gaya unrolled yang lama, relasi yang sama jatuh ke tier 16, sekitar 400 detik dan 21–22 GB, yang akan mengecualikan wallet 16 GB.

Proving bersifat CPU-bound, dan wallet saat ini menggunakan backend CPU di semua platform. Pada percobaan tier besar, prover berjalan single-threaded: droplet 16 vCPU berjalan pada 99% dari satu core, dan memori, bukan jumlah core, yang menentukan apakah sebuah bukti selesai (memori proving). Flag --cuda pada send, bond, call, deploy, bridge-mint, dan bridge-burn memilih backend NVIDIA yang memerlukan build dengan --features cuda. Kernel-nya pertama kali dijalankan pada perangkat keras sungguhan, sebuah NVIDIA H100, pada 2026-09-28 dan cocok dengan referensi CPU, tetapi tidak ada PTX yang di-commit pada checkout circuits yang di-vendor oleh rilis, sehingga build gagal dengan no PTX for the GPU kernels sampai kernel dikompilasi. Belum ada production proof yang diukur pada node GPU fleet. Memang sengaja tidak ada fallback ke CPU. Sebuah call CUDA juga tidak dapat menyegel input envelope, karena salt tidak pernah meninggalkan prover. Memori puncak untuk sebuah bundle proof aset tersembunyi tier 14 adalah sekitar 5,7 GB (Production FRI, CPU); kelas memori yang lebih besar berkaitan dengan bukti interpreter dan rekursi di bawah ini (≥ 64 GB ke atas).

Cara node memverifikasi

Admisi menjalankan pemeriksaan yang murah terlebih dahulu (Transaksi), lalu:

• menghitung ulang bundle digest dari plaintext yang dipublikasikan (anchor, empat nullifier, empat komitmen, fee, burn_a, burn_r, burn_asset, time, auth_commit milik bundle, dan sebuah kata taint yang ditetapkan nol) dan mewajibkannya sama dengan yang dipublikasikan oleh bukti — bukti yang witness-nya melanggar relasi mempublikasikan digest tercemar yang tidak cocok dengan plaintext mana pun. Beberapa pemeriksaan bersifat struktural: guest sendiri yang menyediakan pengirim, aset, dan waktu sebuah output, sehingga prover tidak dapat memilihnya, dan aset privat tidak ada dalam digest;
• men-decode bukti dan memeriksa tinggi yang dideklarasikannya terhadap tier (check_declared_heights), sehingga batas chain atas bentuk sebuah bukti ada pada verifier. Sebelum tanda tangan atau bukti apa pun diperiksa, penyaringan bukti kanonik dijalankan pada setiap transaksi yang disubmit atau digosipkan (dan, di bawah hardening_v6, pada validasi blok); sejak fullnode v0.6.8 (audit v6, ZKV-4) penyaringan itu pertama-tama membatasi setiap derajat yang dideklarasikan pada 25 bit (MAX_HONEST_DEGREE_BITS, batas atas tabel memori ditambah satu), sehingga header dengan derajat sangat besar tidak lagi menahan sebuah node selagi jadwal folding yang jujur diturunkan ulang untuknya, dan panic di dalam penyaringan membuat transaksi itu ditolak alih-alih menghentikan node;
• menghitung binding transaksi dan menjalankan Machine::verify_public(hc_bundle, &binding, proof) — verifier batch ditambah pemeriksaan bahwa H_PUB adalah digest dari kedelapan kata tersebut, sehingga bukti yang disalin ke transaksi dengan aksi lain, envelope lain, atau chain id lain, atau pada chain 20 ke genesis chain lain, tidak lolos verifikasi (hingga chain 13 segmennya kosong dan tidak ada yang mengikat bukti pada transaksinya);
• memverifikasi auth proof terhadap hc_auth dan binding yang sama, dan mewajibkan c yang dipublikasikannya sama dengan auth_commit. Bundle tanpa auth proof ditolak (AuthMissing), begitu pula bundle yang c-nya berbeda (AuthMismatch);
• mewajibkan GAS_LIMIT milik bundle proof sama dengan bundle_gas_limit genesis, yaitu 20.479, dan milik auth proof sama dengan 1.279, batas atas header kedua guest tersebut (BundleGasLimit, AuthGasLimit);
• untuk sebuah call, melakukan hal yang sama terhadap code_hash program yang tersimpan, dengan kata-kata publik program diikuti binding call sebagai segmennya (sebuah Invoke RPL-2 menambahkan transisinya sebagai kata konteks, Program), lalu memeriksa fee terhadap gas limit yang dideklarasikan bukti dan ukuran byte-nya (Fee).

Transaksi yang disubmit lewat RPC atau gosip diverifikasi pada salah satu dari empat worker di belakang antrean sedalam 64, di luar loop konsensus, dan baru digosipkan lebih lanjut setelah lolos verifikasi; token bucket per peer (burst 16, isi ulang 4 per detik) membatasi seberapa banyak yang dapat dibuat seorang peer untuk diverifikasi oleh node, dan cache 8.192 entri menjawab pengulangan transaksi yang ditolak secara permanen tanpa biaya. Verifikasi bukti di dalam blok yang diusulkan tetap berjalan pada loop konsensus ketika blok diterapkan. Node yang melakukan sinkronisasi memverifikasi ulang setiap sertifikat dan setiap bukti dari setiap blok sebelum menerimanya; tidak ada yang dipercaya hanya karena sebuah kuorum menandatanganinya.

Tier

Sejak fullnode v0.5.6 (2026-09-25), bukti call di atas tier 14 ditolak (CallTierTooHigh) sebelum verifier key dibangun, dan blok yang membawanya tidak valid; sebuah call juga boleh membawa paling banyak 128 permutasi Keccak-f dan 128 kompresi SHA-256. Tier 16 sampai 20 masih dapat di-prove, tetapi hanya di luar chain: tidak ada baris di atasnya yang dapat dipanggil pada chain 20, dan chain 20 menolak deploy program yang terlalu besar untuk call tier 14 mana pun, yaitu lebih dari 8.180 kata tanpa input publik (ProgramUncallable) (anggarannya).

Prover memilih tier terkecil yang anggarannya mencakup siklus ditambah baris digest program dan input; eksekusi yang tidak muat gagal sebelum proving. Hanya tier yang bersifat publik. Setiap langkah kira-kira melipatempatkan waktu proving dan menambah sedikit ukuran bukti. Pada chain 20, fee sebuah call mengikuti gas limit yang dideklarasikan buktinya dan ukurannya dalam byte, bukan tier (Fee).

Constraint set dan hard fork

Constraint set adalah himpunan pasti dari tabel, kolom, bus, nilai publik, dan parameter FRI yang diperiksa verifier. Bukti yang dibuat di bawah satu set tidak lolos verifikasi di bawah set lain, ke arah mana pun, dan replay saat startup sebuah node memverifikasi ulang setiap bukti dalam chain-nya — sehingga node yang dibangun dari set berbeda gagal pada bukti pertama dan memotong chain-nya. Itulah sebabnya setiap perubahan pada set dirilis sebagai chain id baru dengan semua node pada satu build, dan mengapa rand_status melaporkan hc_bundle dan hc_auth, serta node yang build-nya tidak sesuai dengan genesis menolak untuk start.

Chain 14 dan 15 tidak mengubah constraint apa pun. Node chain 15 menyimpan 86 konstanta ronde Poseidon2 sebagai tabel literal alih-alih hasil penarikan berbenih (audit ZKV-2) — nilainya sama, sehingga tidak ada hash, digest, atau bukti yang bergeser. Chain 14: bundle aset tersembunyi adalah guest baru (sebuah hc_bundle baru) dan binding transaksi menggunakan segmen publik yang sudah diikat oleh set 6 di dalam sirkuit. Namun, ini tetap sebuah hard fork — format wire bundle, guest yang dipin, dan setiap id transaksi berubah, transaksi chain 13 yang membawa bundle ditolak oleh build baru, dan wallet yang dibangun sebelum fork menghasilkan bukti bersegmen kosong yang ditolak chain.

Ketiga chain berikutnya masing-masing mengubah apa yang dimaksud dengan sebuah bukti. Chain 16 (fullnode v0.6.1, 2026-09-28) beralih ke constraint set 7, mengunci bundle guest v2 yang bebas percabangan (branch-free) dan menetapkan hardening_v6, setelah tinjauan 2026-09-27 menunjukkan bahwa tabel pendek dan terminal LogUp tanpa blinding membocorkan data privat (Cara kerja zkVM). Setiap kunci verifier berubah. Chain 17 (v0.6.3, 2026-09-29) mempertahankan set 7 dan menambahkan otorisasi terpisah: bundle guest v3, auth guest, dua field baru pada wire bundle, dan domain id transaksi rand-txid-3. Chain 18 (v0.6.7-rc1, 2026-09-29) beralih ke constraint set 8 untuk gas meter. Biayanya yang terukur pada ukuran bukti kurang dari 1%. Chain 19 (2026-10-01) adalah re-genesis chain 18 pada build v0.6.7 yang sama dan tidak mengubah apa pun pada bukti. Chain 20 (fullnode v0.6.8, 2026-10-01) mempertahankan constraint set 8 serta guest dan kunci verifier yang sama, dan mengubah hal yang menjadi ikatan sebuah bukti: binding transaksi dan binding panggilan membawa hash genesis (binding_domain: 1), sebuah input publik yang dihitung oleh wallet dan ledger, sehingga tidak ada sirkuit yang berubah. Meski demikian, ini tetap merupakan hard fork, karena bukti dari wallet v0.6.7 tidak terverifikasi di dalamnya. Setiap build menolak chain-chain sebelumnya berdasarkan hash genesis.

Dua catatan audit yang tertanam dalam kode dan layak diketahui: nilai publik TIER diperiksa oleh verifier terhadap header bukti dan degree bits batch, tetapi tidak dibatasi oleh sirkuit itu sendiri (audit ZL1, ditandai untuk set berikutnya dan tidak diperbaiki, karena penghapusannya menggeser tata letak public-values); dan H_IN adalah komitmen yang terlihat oleh guest yang tidak dibandingkan oleh verifier dengan nilai yang diberikan pemanggil, sesuai rancangan.

Mendatang: agregasi blok

Pada sekitar 1,43 MB per bukti bundle aset tersembunyi di chain 14 dan 15, sebuah blok 4 MiB (bawaan, dan milik chain 12) memuat dua transfer terlindung; blok itu memuat tiga pada bundle 2-in-2-out yang berukuran ~1,3 MB. Chain 13, 14 dan 15 menaikkan batas blok menjadi 20 MiB (max_block_bytes), cukup untuk empat belas. Chain 20 mempertahankan 20 MiB, dan sebuah transfer di sana membawa sekitar 2,87 MB bukti, sehingga sebuah blok memuat sekitar tujuh. Solusi yang dipilih fullnode (2026-09-12) dibandingkan pemangkasan (pruning) dan blok yang lebih besar adalah agregasi tingkat blok: satu bukti rekursif per jendela tersegel yang memverifikasi N bukti bundle, sehingga riwayat tetap membawa bukti dari ujung ke ujung sementara bukti mentahnya dapat dibuang. Fitur ini sudah dibangun dan digabungkan (merged) tetapi belum diaktifkan, dan sejak chain 14 fitur ini harus diukur ulang sebelum dapat diaktifkan: bentuk bundle yang diterimanya diukur dengan segmen publik kosong (public 2), sedangkan bundle yang terikat pada transaksi mendeklarasikan public 4, sehingga tidak ada bundle yang dibuktikan di chain 14 yang cocok dengannya. Constraint set 7 dan 8 kembali menggeser bentuk itu: sebuah bukti bundle kini mendeklarasikan public 7 dan memublikasikan 35 nilai, sehingga antarmuka agregat adalah 35 word per bukti. Build node menolak untuk berjalan pada genesis apa pun yang memuat bagian aggregation, dan chain 14 sampai 20 dibuat tanpa bagian itu. Genesis dengan harga gas dinamis, seperti milik chain 20, juga ditolak jika disertai bagian aggregation. Sejak fullnode v0.5.8 bukti agregat juga mengikat agregatornya (audit AGG-2: program menyerap aggregate_binding(chain_id, aggregator, nonce)), sehingga digest program dari bentuk yang diterima harus diukur pada build yang memuat perubahan tersebut. Aktivasi juga masih menunggu uji pemalsuan agregat dari ujung ke ujung terhadap verifier rekursi yang telah diperbaiki, yang belum dijalankan, dan keputusan tentang bukti auth: program agregat hanya memverifikasi bukti bundle, sehingga pada chain dengan otorisasi terpisah, penyegelan sebuah jendela akan mengecilkan sebuah transfer dari sekitar 2,87 MB menjadi sekitar 1,37 MB, bukan menjadi nol.

Yang sudah dibangun:

• mesin kedua yang berbasis Goldilocks (recursion VM, randprotocol-rvm) yang program verifier-nya memeriksa bukti RV32 dalam sekitar 1,97 juta baris pada tier 21 (2.044.506 di bawah constraint set 7), dan program agregat generik-N atas satu jendela bukti bundle;
• dua peran: validator tetap murah bagi CPU dan memverifikasi satu agregat per blok tersegel; aggregator (register terikat jaminan (bonded) yang permissionless dengan alamat pembayaran terlindung) membuktikan agregat pada mesin kelas GPU dan dibayar bagian pembuktian dari bundle yang tercakup ditambah subsidi blok berupa RAND baru dengan jadwal halving;
• lima aksi (RegisterAggregator, UnbondAggregator, WithdrawAggregator, SlashAggregator, Aggregate; SlashAggregator tetap ada pada wire dan ditolak, karena agregat yang dicoba ulang menandatangani ulang nonce yang sama dan itu bukan equivocation), admisi sembilan langkah, penyegelan dan pemangkasan bundle yang tercakup hingga sekitar 3 KB field publik per bundle, sinkronisasi bentuk tersegel yang membebani node baru dengan satu verifikasi rekursi per jendela, metode RPC rand_getAggregate, rand_getAggregators, rand_getUnsealed, rand_getRawTransaction, dan daemon rand-node aggregate --watch.

Terukur pada profil FRI uji: satu agregat N=1 dibuktikan dalam sekitar 26 menit pada laptop yang sedang sibuk (327.035 byte); node baru menerapkan batch tersegel tujuh blok dalam waktu kurang dari satu detik dengan satu verifikasi rekursi. Kelas mesin sebagaimana dibatasi pada awalnya: N=1 membutuhkan ≥ 64 GB memori host, N=2 ≥ 128 GB, N=3 ≥ 160 GB; produksi N ≥ 2 menjadi bagian backend CUDA, yang membutuhkan node GPU yang belum ada. Terukur pada mesin 256 GB di bawah constraint set 7 (2026-09-28 dan 29), agregat N=2 memakai 133 GB, N=3 memakai 221 GB, dan bukti keluar produksi (program verifier atas satu bukti dalam) melebihi 256 GB. Tidak satu pun dari ini telah diukur ulang di bawah constraint set 8. Hingga agregasi diaktifkan, tidak ada agregat yang menggantikan bukti di chain 20: dua node arsipnya menyimpan setiap bukti mentah, dan validatornya memangkas riwayat yang lebih tua dari 24 jam.