Halaman ini mencatat alasan di balik setiap keputusan desain utama di Rand: properti yang harus disediakan sebuah komponen, asumsi yang mendasari penyediaan properti tersebut, dan biaya yang diterima sebagai imbalannya. Halaman ini disusun pada 29 September 2026 dari situs ini, ringkasan whitepaper, dan full node referensi (github.com/randprotocol/fullnode: README, docs/, dan docs/superpowers/specs/). Setiap jawaban mengutip dokumen yang memuat alasannya; path merujuk ke repositori fullnode kecuali diawali dengan randprotocol.org.
Status. Rand berjalan pada testnet yang dioperasikan oleh tim pendiri, dan protokol ini belum diaudit secara independen. Beberapa keputusan di bawah ini diimplementasikan secara bertahap melalui chain cut. Seluruh angka merupakan hasil pengukuran node yang berjalan pada saat penyusunan; angka-angka tersebut diperkirakan akan berubah dan perlu diukur ulang sebelum dikutip.
Primitif kriptografi
1. Mengapa ML-KEM-768 (Kyber) untuk enkripsi note?
Plaintext sebuah note dienkripsi kepada penerimanya dalam sebuah amplop yang tetap berada di ledger publik tanpa batas waktu. Kerahasiaannya karena itu merupakan properti yang tidak dapat dicabut (pertanyaan 8): musuh yang memperoleh komputer kuantum yang relevan secara kriptografis pada waktu kapan pun di kemudian hari dapat mendekripsi setiap amplop historis yang disegel dengan KEM kurva eliptik, karena algoritma Shor menyelesaikan logaritma diskret dalam waktu polinomial. ML-KEM distandarkan dalam NIST FIPS 203 dan keamanannya direduksi ke Module-LWE, yang belum diketahui memiliki algoritma kuantum yang efisien. Set parameter 768 (kategori 3 NIST) dipilih sebagai kompromi antara margin keamanan dan kunci enkapsulasi sebesar 1.184 byte yang harus dibawa oleh setiap alamat. Amplop tersebut adalah ML-KEM-768 yang dikombinasikan dengan ChaCha20-Poly1305: 1.348 byte, atau 1.860 byte dengan field memo tetap.
Sumber: randprotocol.org (bagian post-quantum); README fullnode; docs/shielded.md §2
2. Mengapa komitmen Poseidon2 dan bukan Pedersen?
Komitmen Pedersen bersifat hiding secara sempurna tetapi hanya binding secara komputasional, dan sifat binding-nya direduksi ke asumsi logaritma diskret, yang dipatahkan oleh musuh kuantum; musuh yang mampu menghitung logaritma diskret dapat membuka sebuah komitmen ke nilai yang berbeda. Karena komitmen yang dipublikasikan hari ini harus tetap sound dan hiding selama masa hidup ledger, skema tersebut harus bertumpu pada asumsi yang diyakini tetap berlaku terhadap musuh kuantum, yang dalam praktiknya berarti fungsi hash. Poseidon2 adalah hash yang berorientasi aritmetisasi dan didefinisikan atas field Goldilocks, sehingga evaluasinya di dalam STARK membutuhkan sedikit constraint. Hash yang sama menginstansiasi komitmen note, pohon Merkle berkedalaman 32, dan nullifier.
Sumber: randprotocol.org (bagian post-quantum); docs/shielded.md §1–2
3. Mengapa dua fungsi hash — BLAKE3 dan Poseidon2?
Kedua fungsi ini dioptimalkan untuk model biaya yang berbeda. Poseidon2 digunakan di mana pun sebuah hash harus dievaluasi di dalam proof — note, pohon komitmen, nullifier, dan tabel internal zkVM — karena biayanya diukur dalam constraint. BLAKE3 digunakan di mana pun tidak ada proof yang terlibat dan throughput native menjadi faktor dominan: hash blok, state root atas pohon, himpunan nullifier, register validator, dan tabel program, serta alamat validator (digest BLAKE3 dari kunci publik). Poseidon2 relatif lambat pada CPU; BLAKE3 relatif mahal untuk diaritmetisasi. Masing-masing hanya digunakan di tempat model biayanya berlaku.
Sumber: README fullnode (baris signatures / hashes); docs/architecture.md
4. Mengapa Dilithium2 (ML-DSA) untuk tanda tangan validator?
Tanda tangan konsensus menyediakan properti yang dapat diperbarui (pertanyaan 8): patahnya skema tersebut di kemudian hari memungkinkan pemalsuan pesan di masa depan tetapi tidak membatalkan secara retroaktif blok yang telah difinalisasi, sehingga skema tersebut pada prinsipnya dapat diganti sebelum musuh kuantum ada. Skema lattice tetap diadopsi sejak genesis agar suara konsensus, tanda tangan bersama para guardian bridge, dan register validator memakai satu jenis kunci post-quantum yang sama. Node mengimplementasikan set parameter Dilithium2 ronde 3 (crate crystals-dilithium), yang berbeda dari ML-DSA-44 pada FIPS 204 final; kunci publik berukuran 1.312 byte dan tanda tangan 2.420 byte.
Sumber: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §2; randprotocol.org
5. Mengapa STARK transparan (FRI atas Goldilocks) dan bukan SNARK?
Pilihan ini bertolak dari tiga persyaratan. Pertama, tanpa penyiapan tepercaya: soundness hanya bertumpu pada ketahanan tabrakan sebuah fungsi hash, bukan pada structured reference string atau kurva yang ramah pairing. Kedua, soundness post-quantum yang masuk akal: argumen ini tidak membuat asumsi logaritma diskret maupun pairing. Ketiga, kompatibilitas dengan skema komitmen berbasis hash pada pertanyaan 2. Biayanya adalah ukuran proof: proof sebuah bundle berukuran sekitar 1,3 MB, 300–600 kali ukuran transaksi shielded Zcash atau Monero. Biaya ini diterima dan ditangani secara terpisah melalui agregasi tingkat blok (pertanyaan 31 dan 34).
Sumber: randprotocol.org; docs/block-space.md §1; docs/zkvm.md
6. Mengapa profil FRI 80 query dan bukan 27?
Profil produksi (80 query, blowup factor 8, proof-of-work grinding 20 bit) menyediakan soundness yang dapat dibuktikan sekitar 86 bit, dibandingkan sekitar 42 bit pada profil 27 query, dengan ukuran proof 2,75 kali lebih besar. Waktu verifikasi nyaris tidak berubah: 809 ms naik menjadi 838 ms pada kondisi cold, dan sekitar 16 ms pada kondisi warm. Soundness yang dapat dibuktikan diberi prioritas di atas ukuran proof, dan biaya ukuran dialihkan ke desain block-space dan agregasi.
Sumber: docs/block-space.md §1, §3
7. Mengapa klaim post-quantum dinyatakan per primitif dan bukan ‘sebesar 128 bit untuk seluruh protokol’?
Draf-draf sebelumnya menyatakan keamanan post-quantum 128 bit untuk protokol secara keseluruhan. Klaim itu tidak konsisten dengan batas Brassard–Høyer–Tapp, yang menyatakan bahwa musuh kuantum menemukan tabrakan pada hash 256 bit dalam sekitar 2^85 query, sehingga klaim tersebut ditarik, bukan dikualifikasi. Paper kini menyatakan keamanan per primitif dan per peran — hash transkrip 384 bit, hash 256 bit yang hanya digunakan di tempat ketahanan preimage diperlukan, Dilithium2, ML-KEM-768, dan FRI atas field ekstensi — di bawah asumsi Module-LWE dan Module-SIS dengan fungsi hash dimodelkan sebagai quantum random oracle. Hash transkrip node saat ini adalah Poseidon2; dokumentasi mencantumkan hal ini sebagai kesenjangan konfigurasi yang masih terbuka.
Sumber: randprotocol.org (bagian post-quantum)
8. Apa itu klasifikasi ‘tidak dapat dicabut vs dapat diperbarui’ dan mengapa klasifikasi ini menentukan pilihan?
Sebuah properti keamanan bersifat tidak dapat dicabut jika musuh yang memperoleh kemampuan baru pada waktu kapan pun di masa depan dapat melanggarnya secara retroaktif untuk data yang sudah dipublikasikan; kerahasiaan note dan sifat hiding komitmen termasuk jenis ini, sehingga keduanya harus tahan kuantum pada saat publikasi. Sebuah properti bersifat dapat diperbarui jika ditegakkan kembali pada setiap penggunaan, sehingga skemanya dapat diganti sebelum ancaman terwujud; tanda tangan dan soundness proof termasuk jenis ini. Setiap pilihan primitif dalam bagian ini berasal dari klasifikasi properti yang dilindunginya.
Sumber: randprotocol.org (bagian post-quantum)
Shielded pool
9. Mengapa model note/UTXO tanpa akun atau saldo?
Ledger berbasis akun mempublikasikan saldo secara inheren; menyembunyikannya menuntut enkripsi state dan pembuktian pernyataan atas ciphertext, yang jauh lebih mahal. Note pool hanya menyimpan komitmen dan nullifier, yang keduanya tidak mengungkap pemilik maupun jumlah, sehingga state publik tidak memuat informasi saldo. Satu-satunya pengecualian adalah register validator, yang bobot stake-nya harus publik agar replika menyepakati keanggotaan kuorum (pertanyaan 29).
Sumber: docs/shielded.md §1–2; docs/staking.md §1
10. Mengapa alamat berukuran ~1,6 KB?
Alamat shielded terdiri atas field pemilik pk sebesar 32 byte dan kunci enkapsulasi ML-KEM-768 sebesar 1.184 byte yang dibutuhkan pengirim untuk menyegel amplop; setelah dikodekan base58, ukurannya sekitar 1.667 karakter. Panjang ini merupakan konsekuensi langsung dari KEM post-quantum. Sebuah desain yang telah disetujui (alamat shielded pendek, 2026-09-17) mengganti alamat tersebut dengan pengenal penerima sekitar 256 bit yang diresolusikan ke sebuah record yang dapat diperbarui, ditandatangani dengan spend key dan disajikan oleh explorer, sehingga kunci enkapsulasi diambil, bukan disalin secara manual.
Sumber: docs/shielded.md §1; docs/superpowers/specs/2026-09-17-short-shielded-address.md
11. Mengapa setiap kunci diturunkan dari satu spend key 256 bit?
Seluruh materi kunci lainnya merupakan fungsi deterministik dari satu rahasia sk: viewing key nk = H(NK, sk), field pemilik pk = H(PK, nk), nullifier H(NF, nk, cm), outgoing viewing key, dan kunci dekapsulasi ML-KEM, masing-masing dengan domain separator sendiri. File kunci karena itu hanya menyimpan sk, cadangan berupa satu nilai, dan pemindaian ulang pohon dari leaf 0 memulihkan setiap note. Karena tidak ada salinan kedua untuk pemulihan, wallet menolak menimpa file kunci yang sudah ada.
Sumber: docs/shielded.md §1
12. Mengapa bentuk bundle tetap 4-in-4-out?
Bentuk yang tetap membuat setiap bundle memiliki ukuran dan struktur yang sama apa pun yang dipindahkannya. Setiap bundle mempublikasikan tepat empat nullifier dan empat komitmen; slot yang tidak terpakai diisi note dummy bernilai nol, dan output kembalian dipublikasikan meskipun nilainya nol, karena ketiadaan output kembalian akan membedakan transaksi tersebut. Spesifikasi awalnya adalah 2-in-2-out, mengikuti Sapling. Spesifikasi itu diperlebar menjadi 4-in-4-out bersama bundle aset tersembunyi, sehingga slot 0–1 membawa aset privat dan slot 2–3 membawa RAND untuk biaya; empat slot, bukan tiga, memungkinkan transfer token membayar biayanya dari hingga dua note RAND.
Sumber: docs/shielded.md §2; docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §3
13. Mengapa satu proof dapat memindahkan aset apa pun (RAND, zUSD, token RPL)?
Sebelum chain 14, sebuah transfer token membawa dua bundle, satu untuk biaya RAND dan satu untuk aset. Hal ini memerlukan dua bukti dan mengungkapkan kepada pengamat mana pun token apa yang berpindah. Guest hidden-asset menerima pengenal aset sebagai input privat, sehingga transfer zUSD tidak dapat dibedakan dari pembayaran RAND. Guest tersebut muat pada tier 14 (sekitar 100 s dan 5,7 GB memori) hanya karena guest itu membaca inputnya dalam sebuah loop dan menggabungkan pemeriksaan keanggotaan Merkle; implementasi yang di-unroll sepenuhnya memerlukan tier 16 (sekitar 400 s dan 21 GB), yang melampaui memori mesin 16 GB.
Sumber: docs/superpowers/specs/2026-09-19-hidden-asset-bundle-design.md §1–3
14. Mengapa biaya bersifat publik dan dibayarkan kepada proposer?
Biaya publik konsisten dengan register stake yang bersifat publik dan membuat admisi menjadi murah: sebuah node dapat memeriksa batas minimum biaya sebelum melakukan verifikasi apa pun. Bukti bundle menegakkan persamaan keseimbangan Σ input = Σ output + biaya + burn, sehingga biaya dibayarkan dari note tersembunyi tanpa mengungkapkan note mana. Biaya yang diterima adalah bahwa jumlah biaya dapat mengungkapkan kelas transaksi (transfer atau pemanggilan program).
Sumber: docs/superpowers/specs/2026-09-11-shielded-pool-design.md (tabel putusan); docs/fees.md §1
15. Mengapa deposit (mint, bridge attest) memiliki jumlah yang bersifat publik?
Nilai yang masuk ke dalam pool harus dicatat secara publik, dan atestasi bridge merupakan bukti publik bahwa penguncian yang bersesuaian telah terjadi pada chain sumber. Visibilitas yang timbul terbatas pada langkah masuk, analog dengan transaksi transparent-to-shielded (t-to-z) di Zcash; pengeluaran berikutnya atas note yang didepositkan bersifat tersembunyi.
Sumber: docs/superpowers/specs/2026-09-11-shielded-pool-design.md; docs/shielded.md (tabel apa yang bersifat publik)
16. Mengapa memo berupa field tetap sebesar 512 byte?
Field dengan panjang tetap memastikan bahwa ledger tidak mengungkapkan apakah sebuah memo ada atau berapa panjangnya: pada chain yang mendukung memo, setiap envelope pembuat note, termasuk dummy dan kembalian, berukuran tepat 1.860 byte. Memo hanya dibawa di dalam envelope terenkripsi, tidak pernah di dalam note, komitmen, atau bukti, dan dapat dibaca persis oleh pihak-pihak yang sudah dapat mendekripsi note tersebut. Memo yang cacat didekode sebagai memo kosong, sehingga tidak dapat membuat note itu sendiri tidak dapat dipulihkan.
Sumber: docs/shielded.md §2; docs/superpowers/specs/2026-09-26-address-sharing-and-memo-design.md
17. Mengapa pembuktian dilakukan secara lokal, dan bagaimana prover terdelegasi tidak merusak hal itu?
Bukti itu sendiri adalah otorisasi pengeluaran: sebuah bundle tidak membawa tanda tangan maupun field pengirim, sehingga kunci pengeluaran tidak perlu meninggalkan wallet. Bukti bundle tier 14 memerlukan memori sekitar 5,7 GB, yang melampaui kemampuan ponsel dan browser, dan karena itu diperlukan prover terdelegasi. Otorisasi terpisah (bundle guest v3, parameter genesis hc_auth) memisahkan kedua peran tersebut: prover hanya menerima kunci pandang nk dan menghasilkan bukti bundle, sedangkan wallet menghasilkan bukti otorisasi tier 10 yang kecil menggunakan sk. Dengan demikian, prover dapat membangun bukti bundle tetapi tidak dapat mengotorisasi pengeluaran (pertanyaan 36).
Sumber: docs/prover.md §1; docs/shielded.md (otorisasi terpisah); docs/superpowers/specs/2026-09-28-delegated-proving-design.md
18. Mengapa jendela anchor sebesar 256 blok?
Sebuah bukti dibangun terhadap root commitment tree tertentu (anchor-nya), dan pembangunan bukti bundle tier 14 memakan waktu sekitar 100 s. Oleh karena itu, ledger harus menerima anchor yang telah berumur beberapa menit pada saat pengiriman. Jendela tersebut semula 64 blok dalam spesifikasi awal dan diperlebar menjadi 256 blok seiring menurunnya interval blok, sehingga durasinya dalam waktu jam dinding tetap di atas waktu pembuktian.
Sumber: docs/shielded.md; docs/superpowers/specs/2026-09-11-shielded-pool-design.md
zkVM dan komputasi konfidensial
19. Mengapa RV32I sebagai ISA guest (dan bukan RV64)?
Sebuah word 32-bit terdekomposisi tepat menjadi empat limb byte, dan bilangan prima Goldilocks p = 2^64 − 2^32 + 1 cukup besar sehingga hasil kali dua nilai 32-bit tidak pernah meluap dari field. RV64 akan menggandakan jumlah kolom limb pada tabel ALU dan memori. RISC-V juga merupakan target yang sudah ada pada compiler arus utama, sehingga program guest adalah biner hasil kompilasi biasa, bukan program dalam bahasa yang dibuat khusus.
Sumber: docs/zkvm.md §2; research/docs/01-isa.md (‘Why RV32, not RV64’)
20. Mengapa Goldilocks dan bukan field 256-bit?
Goldilocks adalah bilangan prima 64-bit yang aritmetikanya terpetakan secara efisien ke instruksi CPU 64-bit native, dan grup multiplikatifnya memiliki subgrup pangkat dua yang besar, sebagaimana disyaratkan FRI. Bersama dengan word 32-bit, hal ini menjaga setiap baris trace tetap sempit, sehingga pembuktian dengan profil produksi layak dilakukan pada laptop. Soundness yang hilang akibat bekerja pada field kecil dipulihkan dengan menarik challenge FRI dari field ekstensi.
Sumber: docs/zkvm.md §2; randprotocol.org (bagian performa)
21. Mengapa gas tier dan bukan pengukuran gas per opcode?
Gas per opcode ada di Ethereum karena setiap node mengeksekusi ulang setiap transaksi dan panjang eksekusi tidak dibatasi sebelumnya. Di Rand tidak ada node yang mengeksekusi program: pengirim mengeksekusinya satu kali, off chain, dan node memverifikasi satu STARK yang biaya verifikasinya hanya bergantung pada tier, bukan pada komputasi yang dilakukan. Terminasi ditegakkan oleh tier, karena eksekusi yang tidak berhenti dalam 2^t siklus tidak memungkinkan bukti pada tier t. Penetapan harga berupa batas minimum tetap ditambah estimasi gas yang dibatasi oleh header, dan kapasitas blok berupa anggaran byte. Gas hanya muncul di dalam guest interpreter EVM dan sBPF, sebagai state privat, tempat gas diperlukan untuk mereproduksi semantik chain sumber.
Sumber: docs/fees.md §3–4; docs/superpowers/specs/2026-09-28-gas-model-design.md
22. Mengapa trace dibagi menjadi sembilan tabel yang digabungkan oleh bus LogUp?
Sebuah tabel monolitik tunggal akan mengisi padding setiap baris hingga selebar operasi terlebar. Memisahkan trace menjadi sembilan tabel — CPU, memori, ALU, range, nibble, Poseidon2, program, input, dan public — yang masing-masing diberi padding hanya sampai tingginya sendiri, menjaga total trace tetap kecil. Argumen LogUp menetapkan relasi multiset antartabel. Tabel Keccak dan SHA-256 bersifat opsional dan hanya disertakan ketika guest memanggil system call yang bersesuaian.
Sumber: docs/zkvm.md §5
23. Mengapa sebuah pemanggilan program hanya menerbitkan delapan word output?
Pemanggilan program adalah bukti bahwa kode publik dieksekusi dengan benar pada input privat; ledger hanya mencatat receipt-nya. Delapan word 32-bit sudah cukup untuk mengikat sebuah hasil, sebuah komitmen, atau sebuah keputusan, dan ukuran output yang tetap memastikan bahwa bentuk receipt tidak mengungkapkan apa pun tentang program tersebut. Saat ini output hanya berupa data: sebuah program tidak dapat memindahkan nilai dengan sendirinya.
Sumber: randprotocol.org/usecases (catatan platform); docs/confidential.md
24. Mengapa ada envelope input pemanggilan?
Pemanggil yang menyimpan input privat dapat kemudian menunjukkan atas dasar apa sebuah pemanggilan dihitung. Envelope input pemanggilan membuat hal ini tahan lama dengan menyimpan input, dalam keadaan terenkripsi, bersama pemanggilan tersebut, tempat auditor yang ditunjuk dapat mendekripsinya dengan sebuah kunci. Hal ini memperluas pengungkapan selektif — konfidensial bagi pasar, terbuka bagi regulator yang ditunjuk — dari pembayaran ke eksekusi program.
Sumber: docs/confidential.md (‘Call input envelopes’)
25. Mengapa perubahan constraint set merupakan hard fork?
Setiap node memverifikasi ulang setiap bukti selama sinkronisasi, dan sebuah bukti hanya valid terhadap constraint set (AIR) tempat bukti itu dihasilkan. Perubahan pada AIR karenanya mengubah himpunan chain yang valid, dan perubahan itu diperkenalkan pada sebuah genesis cut, bukan diadopsi node demi node.
Sumber: docs/architecture.md (‘Why a constraint-set change is a hard fork’)
26. Mengapa emulator yang menjadi rujukan, bukan AIR?
Emulator adalah spesifikasi mesin yang dapat dibaca, dan AIR adalah penyandian spesifikasi tersebut sebagai constraint polinomial. Apabila keduanya berbeda, AIR menurut definisi yang keliru. Hal ini menempatkan definisi normatif pada artefak yang paling praktis untuk diaudit oleh manusia.
Sumber: docs/zkvm.md §5
Konsensus dan node
27. Mengapa chained HotStuff BFT?
Chained HotStuff menyediakan finalitas deterministik: dengan kuorum berbobot stake lebih dari dua pertiga, sebuah blok final setelah tiga quorum certificate berturut-turut terbentuk di atasnya, dan blok yang final tidak pernah direorganisasi. Interval blok yang terukur adalah 1,2 s dan waktu hingga finalitas sekitar 3,6 s. Pengguna institusional yang dituju memerlukan finalitas penyelesaian yang dapat mereka jadikan dasar pencatatan, yang tidak disediakan oleh chain dengan finalitas probabilistik.
Sumber: README fullnode; randprotocol.org (bagian performa); docs/architecture.md §6
28. Mengapa verifikasi bukti berada di luar loop konsensus?
Sebuah node memverifikasi setiap STARK ketika menerima transaksi tersebut (sekitar 32 ms dalam keadaan warm), sebelum merelainya, sehingga verifikasi tidak pernah berada pada jalur kritis pengusulan blok. Interval blok dengan demikian ditentukan oleh latensi konsensus, bukan oleh ukuran bukti. Pemeriksaan diurutkan menurut biaya, dengan STARK diverifikasi terakhir, sehingga transaksi yang cacat ditolak sebelum langkah yang paling mahal.
Sumber: randprotocol.org; docs/architecture.md (‘How it works’)
29. Mengapa register validator bersifat publik sementara yang lainnya shielded?
Semua replika harus bersepakat tentang validator mana yang boleh mengusulkan dan suara mana yang membentuk kuorum, yang mensyaratkan bobot stake bersifat publik. Register karenanya memuat jumlah stake secara terbuka. Kaitan dengan kepemilikan tetap tersembunyi: sebuah bond didanai dari sebuah note shielded dan penarikan dibayarkan ke dalam note shielded, dan tidak satu pun operasi mengungkapkan milik siapa note tersebut.
Sumber: docs/staking.md §1
30. Mengapa node yang sedang sinkronisasi mengeksekusi ulang setiap blok alih-alih memercayai sertifikat?
Node yang bergabung belakangan memverifikasi setiap sertifikat kuorum, memverifikasi ulang setiap bukti bundle dan bukti call, serta membandingkan receipt yang dihasilkan sebelum menerima rantai tersebut. Karena validitas ditegakkan oleh bukti dan bukan oleh tanda tangan semata, prosedur ini tidak terpapar serangan long-range yang memengaruhi rantai yang hanya diamankan oleh tanda tangan. Pemangkasan bukti dari riwayat ditolak karena akan menghilangkan jaminan ini.
Sumber: docs/architecture.md; docs/aggregation.md (pendahuluan)
31. Mengapa batas blok dipertahankan pada 4 MiB padahal satu bukti berukuran lebih dari 1 MB?
Dengan batas tetap, ukuran blok tidak dapat bertambah; ketika permintaan melampaui kapasitas, yang dibatasi adalah throughput (tiga transfer shielded per blok pada profil 80 query). Pembatasan throughput dinilai sebagai mode kegagalan yang lebih aman daripada pertumbuhan blok tanpa batas. Solusi yang dipilih adalah agregasi tingkat blok, yaitu satu bukti rekursif per blok, bukan menaikkan batas atau menurunkan tingkat soundness.
Sumber: docs/block-space.md §1, §6
32. Mengapa testnet memangkas riwayat hingga satu hari?
Satu sertifikat kuorum yang membawa 18 tanda tangan Dilithium2 berukuran sekitar 44 KB dan disimpan dua kali per blok. Dengan blok yang sebagian besar kosong setiap 1,4 s, ini berjumlah sekitar 6,6 GB per node per hari; disk node penuh, dan rantai kehilangan kuorum pada ketinggian 248.953. Full node testnet kini menyimpan riwayat satu hari, satu node arsip menyimpan seluruhnya, dan node mainnet akan menyimpan seluruhnya. State buku besar — pohon, himpunan nullifier, register, dan program — tidak pernah dipangkas.
Sumber: docs/superpowers/specs/2026-09-24-history-pruning-design.md
33. Mengapa libp2p?
Node menggunakan TCP dengan Noise dan Yamux, gossipsub untuk transaksi dan suara, Kademlia dengan daftar bootstrap untuk penemuan peer, mDNS pada jaringan lokal, dan request-response untuk sinkronisasi blok. Komponen-komponen ini standar dan banyak digunakan, sehingga node mewarisi penilaian peer, penyambungan ulang, dan peningkatan transport tanpa harus memelihara implementasinya sendiri.
Sumber: README fullnode (baris networking)
Pasar proving dan agregasi
34. Mengapa agregasi bukti tingkat blok?
Ruang blok tumbuh secara linear terhadap jumlah bundle jika setiap bundle membawa buktinya sendiri yang berukuran sekitar 1,3 MB. Satu STARK rekursif per blok, yang memverifikasi seluruh N bukti bundle, menjaga biaya bukti on-chain konstan terhadap N. Validator kemudian memverifikasi satu bukti agregat (sekitar 16 ms warm) pada CPU, sehingga perangkat keras komoditas tetap dapat melakukan validasi, sementara agregator dengan GPU bersaing dalam pasar terpisah yang permissionless untuk memperebutkan bagian biaya proving dan subsidi blok.
Sumber: docs/aggregation.md §1
35. Mengapa tiga peran — validator, agregator, prover terdelegasi?
Ketiga peran memiliki kebutuhan perangkat keras yang berbeda dan dibayar oleh pihak yang berbeda. Validator mengurutkan dan memverifikasi transaksi pada CPU dan dibayar dari bagian biaya verifikasi. Agregator menghasilkan bukti blok rekursif pada GPU dan dibayar dari bagian proving serta subsidi. Prover terdelegasi menghasilkan satu bukti bundle bagi pengirim yang perangkatnya tidak mampu melakukannya (ponsel atau browser) dan dibayar secara privat oleh pengirim tersebut. Pemisahan peran menjaga validasi tetap murah dan membuat proving kompetitif.
Sumber: docs/prover.md §1
36. Mengapa prover terdelegasi tidak dapat mencuri dana?
Dalam otorisasi terpisah, prover menerima viewing key nk tetapi tidak menerima spend key sk. Bukti bundle melakukan komitmen terhadap c = H(AUTH, nk || salt), dan bukti otorisasi terpisah milik wallet menunjukkan pengetahuan atas sk untuk c yang sama. Tanpa sk, prover dapat menghitung bukti bundle tetapi tidak dapat menghasilkan otorisasi yang valid, dan wallet memverifikasi bukti yang dikembalikan sebelum mengirimkannya.
Sumber: docs/shielded.md (otorisasi terpisah); docs/prover.md §8
Bridge dan zUSD
37. Mengapa mengunci USDT/USDC di rantai asalnya alih-alih menerbitkan stablecoin baru?
Penerbitan native di Rand akan membuat kapasitas cadangan bergantung pada keputusan penerapan para penerbit, yang berada di luar kendali proyek. Penguncian USDT dan USDC di Ethereum, BSC, Tron, dan Solana menarik cadangan dari rantai tempat aset-aset ini sudah beredar dan tidak memperkenalkan penerbit baru: setiap unit zUSD merupakan klaim atas USDT atau USDC yang disimpan dalam kontrak kustodi yang dapat dibaca publik.
Sumber: randprotocol.org (bagian cadangan)
38. Mengapa himpunan guardian t-dari-n, dan mengapa dinyatakan secara terus terang?
Atestasi adalah satu-satunya bukti yang tersedia bagi Rand bahwa penguncian terjadi di rantai lain, sehingga atestasi harus ditandatangani oleh kelompok ambang; atestasi yang valid memerlukan tanda tangan dari lebih dari dua pertiga guardian. Asumsi kepercayaan yang dihasilkan dinyatakan secara eksplisit. Jaminan efektif adalah yang lebih lemah antara solvensi cadangan dan integritas bridge; koalisi t guardian dapat mengotorisasi minting tanpa penguncian yang bersesuaian; dan eksposurnya dibatasi oleh kustodi yang disimpan di setiap rantai. Asumsi ini semula merupakan argumen untuk tidak membangun bridge. Asumsi ini tidak dicabut, melainkan diterima sebagai imbalan atas kapasitas cadangan.
Sumber: randprotocol.org (bagian cadangan, ‘What this costs’)
39. Mengapa ada ko-tanda tangan Dilithium2 di samping atestasi ECDSA?
Rantai sumber tidak menyediakan verifier tanda tangan lattice, sehingga rilis di rantai tersebut tetap diamankan oleh ECDSA klasik, dengan eksposur yang dibatasi oleh kustodi dan batas atas. Setiap pesan yang diterima buku besar Rand dari para guardian — deposit dan rotasi himpunan guardian — harus membawa pula kuorum tanda tangan Dilithium2 dari guardian yang sama. Dengan demikian jalur mint bersifat pasca-kuantum meskipun titik akhir eksternalnya tidak. Ko-tanda tangan dikirim bersama atestasi dan tidak memerlukan perubahan pada kontrak yang sudah di-deploy.
Sumber: docs/superpowers/specs/2026-09-19-pq-cosignature-bridge.md §1
40. Mengapa blinding pada note deposit diturunkan, bukan dipilih?
Sebelumnya, komitmen note deposit tidak ditentukan sampai relayer mengirimkan atestasi, sehingga dua relayer dapat mengirimkan atestasi yang sama dengan note yang berbeda. Menurunkan faktor blinding r secara deterministik dari atestasi menetapkan komitmen tersebut, sehingga pengiriman yang bersaing bertabrakan pada satu komitmen dan deposit tidak dapat di-mint dua kali.
Sumber: docs/bridge.md (F1, chain 14)
41. Mengapa USDT yang dikunci di Tron dapat keluar sebagai USDT di Ethereum?
zUSD bersifat fungible: setiap unit merupakan klaim atas cadangan agregat, bukan atas rantai tempat unit itu masuk. Memisahkan jalur masuk dari jalur keluar memungkinkan likuiditas berpindah ke tempat ia dibutuhkan, dengan syarat rantai tujuan memiliki cadangan yang memadai. Makalah stablecoin membuktikan bahwa invarian S ≤ Σ_c R_c, yaitu total suplai dibatasi oleh jumlah cadangan per rantai, dipertahankan oleh setiap transisi state.
Sumber: randprotocol.org (bagian cadangan)
42. Mengapa shielding menyembunyikan distribusi tetapi bukan kuantitas?
Total suplai zUSD bersifat publik dalam registri token dan cadangan setiap rantai merupakan saldo publik, sehingga solvensi dapat diverifikasi oleh siapa pun; yang disembunyikan adalah distribusi kepemilikan di antara para pemilik. Satu keterbatasan berlaku: keempat saldo cadangan tidak dapat diamati secara atomik pada satu saat, sehingga untuk rantai-rantai tersebut pemeriksaan mendeteksi insolvensi setelah kejadian, bukan mencegahnya.
Sumber: randprotocol.org (bagian cadangan)
43. Mengapa burn adalah satu-satunya transaksi yang menyebutkan asetnya?
Burn melepaskan aset tertentu di rantai tertentu, sehingga kontrak kustodi harus mengetahui aset dan rantai yang dimaksud. Setiap transaksi lainnya mentransfer aset yang tidak teridentifikasi. Burn juga membawa biaya bridge, karena burn adalah satu-satunya transaksi bridge yang pengirimnya adalah penerima manfaat.
Sumber: docs/architecture.md; docs/shielded.md §2
Kepatuhan dan pengungkapan
44. Mengapa viewing key, bukan ‘privat dari semua orang’?
Regulator belum menerima sistem privasi yang pengungkapannya bergantung pada kerja sama pihak yang sedang diselidiki, sebagaimana diilustrasikan oleh kasus Tornado Cash. Rand karena itu memperlakukan pengungkapan sebagai objek protokol. Pemegang, atau perantara yang diatur, menyimpan viewing key; auditor dapat mendekripsi transaksi yang disebutkan dalam permintaan yang sah secara hukum; dan target rancangannya adalah kunci terlingkup yang mengungkap pihak lawan dan jumlah tanpa mengungkap strategi perdagangan. Bagi aplikasi seperti penggajian, kemampuan diaudit ini merupakan persyaratan, bukan keterbatasan.
Sumber: randprotocol.org/usecases (bagian regulasi; kasus penggajian)
45. Mengapa outgoing viewing key dipisahkan dari incoming viewing key?
Pemisahan memungkinkan pengirim membuktikan apa yang telah dibayarkannya tanpa memperoleh akses ke riwayat penerima, dan sebaliknya. Outgoing viewing key ovk mendekripsi envelope yang telah dikirim wallet; kunci dekapsulasi ML-KEM mendekripsi envelope yang dikirim kepadanya; dan kunci per transaksi mengungkap tepat satu output kepada pihak ketiga.
Sumber: docs/shielded.md §1–2
Keterbatasan yang diketahui
46. Apa yang dibocorkan oleh bukti saat ini, dan mengapa hal itu didokumentasikan?
Peninjauan tanggal 2026-09-27 menemukan bahwa pada guest v1 (chain 14–15) setiap bukti bundle mengungkap slot input mana yang berisi note sungguhan serta Hamming weight dari setiap indeks leaf yang dibelanjakan. Penyebabnya ada dua: total LogUp per tabel dipublikasikan tanpa blinding, dan alur kontrol guest bercabang bergantung pada apakah suatu input adalah dummy. Solusinya adalah guest tanpa percabangan (v2), yang akan dipilih pada genesis berikutnya. Temuan ini dipublikasikan karena jaringan ini adalah testnet dan dokumentasi berfungsi sebagai catatan auditnya.
Sumber: docs/shielded.md (‘What the proofs leak today’)
47. Mengapa pertumbuhan state dihargai terlalu rendah?
Ethereum menetapkan harga untuk penulisan ke penyimpanan karena state yang tersimpan membebankan biaya permanen pada setiap node. Saat ini Rand menetapkan harga pertumbuhan commitment tree, himpunan nullifier, dan penyimpanan program hanya melalui biaya deployment per word dan biaya bundle tetap. Hal ini memadai untuk testnet, tetapi dicatat sebagai pertanyaan penetapan harga yang masih terbuka dan harus diselesaikan sebelum mainnet; penyelesaiannya tidak memerlukan metering per opcode.
Sumber: docs/fees.md §3 (caveats)
48. Mengapa belum ada audit independen yang diselesaikan?
Protokol ini sedang dalam pengembangan aktif pada testnet yang dioperasikan oleh tim, dan himpunan constraint serta chain cut tambahan diperkirakan masih akan muncul sebelum desainnya stabil. Situs web menyatakan hal ini di setiap halaman. Putaran audit internal (v3–v5) dipublikasikan dalam docs/consensus.md dan spesifikasi desain, sehingga audit eksternal nantinya memiliki rekam jejak yang lengkap sebagai bahan kerja.
Sumber: randprotocol.org (footer); docs/consensus.md