Gunakan halaman ini untuk membuat kunci yang tepat bagi suatu keperluan, untuk mengurai atau memvalidasi sebuah alamat, dan untuk mengetahui apa yang terungkap ketika Anda menyerahkan sebuah kunci kepada orang lain. Tidak ada akun pada chain ini: saldo adalah fakta tentang sebuah file kunci, bukan tentang chain.
Dua kunci, dua jenis alamat
| kunci node | kunci wallet | |
|---|---|---|
| ditulis oleh | rand-node keygen | rand keygen |
| rahasia | seed 32 byte | spend key 256 bit |
| identitas publik | alamat 32 byte, base58, 32 hingga 44 karakter | alamat terlindung (shielded), rand1…, 1.665 atau 1.666 karakter |
| menandatangani | blok, suara, mint faucet, Unbond, Withdraw, sebuah Registration, dan pada chain 20 suara AdmitValidator; sebagai otoritas mint Key milik sebuah token, TokenMint dan SetAuthority. Pada chain 20 setiap pesan ini juga mencakup hash genesis (Transaksi) | tidak ada: sebuah transfer diotorisasi oleh bukti-buktinya |
| muncul di chain sebagai | proposer blok, baris register validator, pembuat mint faucet, otoritas key milik sebuah token | tidak pernah dalam sebuah transfer, karena disegel di dalam amplop. Alamat ini dipublikasikan di tempat nilai masuk ke pool dengan jumlah publik: deposit bridge, mint token, dan pada chain 20 pembayaran dari sebuah invoke menyebutkan alamat penerima; alamat pembayaran seorang validator ada di register, genesis chain 20 menyebutkan treasury biaya bridge, dan sejak chain 14 mint faucet serta catatan alloc genesis mempublikasikan pk pemilik, 32 byte pertama dari alamat |
| file | { "seed", "address", "public_key" }, mode 0600 | { "version": 2, "spend_key": "<64 hex>" }, mode 0600 |
Keduanya tidak pernah bercampur. Validator diidentifikasi dengan jenis pertama, dan bentuk kunci Dilithium2 yang sama melayani otoritas mint Key milik sebuah token (rand token create --authority-key-out menulis file dengan bentuk milik rand-node keygen), kunci jeda bridge, dan enam kunci guardian pasca-kuantumnya. Kunci atestasi para guardian adalah secp256k1, dengan alamat 20 byte bergaya Ethereum (Bridge). Nilai disimpan di bawah jenis kedua.
Alamat transparan
Kunci node adalah seed 32 byte yang darinya sepasang kunci Dilithium2 diturunkan secara deterministik: kunci publik 1.312 byte dan tanda tangan 2.420 byte. Alamat adalah hash BLAKE3 dengan pemisahan domain dari kunci publik, ditulis dalam base58:
address = blake3("rand-address" || public_key) // 32 bytes, shown as base58Objek yang ditandatangani (suara, blok, mint, aksi staking) membawa kunci publik lengkap, sehingga verifikator memeriksa blake3("rand-address" || public_key) == address alih-alih memercayai alamat saja. Seed yang sama juga menghasilkan identitas libp2p node, yaitu kunci ed25519 dari blake3("rand-p2p-identity" || seed), yang merupakan peer id setelah /p2p/ dalam multiaddr bootstrap.
rand-node keygen --out node.key.json # prints the address
rand-node address --key node.key.json # address, public key (hex), libp2p peer idContoh: EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e adalah salah satu validator chain 20. Chain 15 hingga 20 memakai ulang delapan belas kunci yang dirotasi untuk chain 14, sehingga alamat dan peer id mereka tidak berubah, dan tidak ada lagi alamat atau peer id validator chain 13 yang digunakan; delapan validator lagi melakukan bonding pada chain 15, dan seluruh 26 validator ada dalam file genesis sejak chain 16.
Alamat terlindung
Sebuah wallet adalah satu rahasia, yaitu spend key 256 bit sk, dan segala hal lainnya adalah turunannya. Penurunannya memakai Poseidon2 dengan tag domain sebagai kata pertama yang diserap (H(domain, msg)), fungsi yang sama dengan yang dihitung zkVM di dalam sirkuit:
spend key sk 256 bits, in wallet.key.json
│
├─ viewing key nk = H(NK, sk) sees the whole history; cannot spend
│ ├─ pk = H(PK, nk) the field a note names its owner by
│ ├─ nullifier(cm) = H(NF, nk, cm) what a spend publishes
│ ├─ ovk opens envelopes this wallet sent
│ └─ ML-KEM-768 decapsulation key opens envelopes sent to this wallet
└─ address rand1 + base58(pk || kem_ek)Alamat adalah 32 byte pk diikuti kunci enkapsulasi ML-KEM-768 sebesar 1.184 byte, dalam base58 setelah prefiks rand1: 1.665 atau 1.666 karakter (panjang base58 bergantung pada byte-byte awal; sekitar satu dari empat belas alamat berukuran lebih pendek), sekitar 1,6 KB, dan tanpa checksum. Pengirim memerlukan kunci enkapsulasi untuk menyegel amplop catatan, itulah sebabnya kunci itu ada di dalam alamat. Kunci ini publik secara desain: siapa pun boleh membayar ke alamat ini, dan memegangnya tidak mengatakan apa pun tentang apa yang dimiliki alamat tersebut.
rand keygen # wallet.key.json; refuses to overwrite an existing file
rand address # rand1… on stdout, its fingerprint XXXX-XXXX-XXXX-XXXX on stderrSejak v0.5.10 rand address mencetak persis alamat dan satu baris baru pada stdout, sehingga $(rand address) berfungsi dalam skrip. Fingerprint dikirim ke stderr.
Pengurai bekerja persis seperti ShieldedAddress::parse: buang rand1, dekode base58, dan wajibkan tepat 32 + 1.184 = 1.216 byte; 32 byte pertama adalah pk sebagai delapan kata u32 little-endian, sisanya adalah kunci enkapsulasi. RPC menolak parameter apa pun yang lebih panjang dari 2.000 karakter sebelum menguraikannya.
Di samping file kunci, wallet menyimpan <key>.key.json.notes.json, sebuah cache berisi catatan yang telah dibuka oleh kunci ini. Cache ini memuat plaintext catatan, sehingga ditulis dengan mode 0600 seperti kuncinya; setiap barisnya dapat dipulihkan dengan memindai ulang dari leaf 0.
Membagikan alamat: fingerprint dan tautan randpay:
Alamat terlalu panjang untuk dibacakan atau dibandingkan dengan mata dan tidak memiliki checksum, sehingga sejak v0.5.10 setiap wallet menampilkan fingerprint di sampingnya. Fingerprint hanya untuk tampilan: tidak ada yang ada di chain maupun di jaringan yang membawanya.
fingerprint = first 80 bits of blake3("rand-address-fingerprint-1" || pk_bytes || kem_ek)
= 16 Crockford base32 characters, shown as XXXX-XXXX-XXXX-XXXXHash dihitung atas 1.216 byte mentah yang dikodekan oleh alamat. Alfabetnya adalah 0123456789ABCDEFGHJKMNPQRSTVWXYZ; pengurai mengabaikan huruf besar/kecil dan tanda hubung, serta membaca O sebagai 0 dan I atau L sebagai 1.
Sebuah tautan randpay: membawa sebuah alamat dan, secara opsional, apa yang harus dibayarkan kepadanya:
randpay:<rand1…>[?amount=<decimal>][&asset=<index | 64 hex | rpl1…>][&memo=<percent-encoded UTF-8>]amount dinyatakan dalam satuan tampilan aset (RAND desimal dengan sembilan desimal, token dengan decimals milik baris registrinya sendiri) dan tidak boleh nol. memo paling banyak 510 byte UTF-8. Skema dicocokkan tanpa memperhatikan huruf besar/kecil; parameter yang tidak dikenal, parameter yang berulang, atau percent-encoding yang salah akan ditolak.
rand address --uri --amount 1.5 --memo "invoice #42" --qr # a randpay: link, as a terminal QR
rand contacts add alice rand1q9f… # shows the fingerprint, asks add? [y/N]
rand send alice 1.5 --memo "coffee" # to a contact, with a memorand send <TO> menerima alamat rand1…, tautan randpay:, atau nama kontak yang tersimpan, dicoba dalam urutan tersebut. amount, asset, dan memo dari sebuah tautan mengisi apa yang tidak ditentukan baris perintah, dan nilai yang diberikan dengan kedua cara tetapi tidak sama akan ditolak. Sebelum membuktikan, send mencetak to <contact, if any> · fingerprint XXXX-XXXX-XXXX-XXXX · <amount> <asset> lalu meminta konfirmasi; skrip memberikan --yes. Kontak disimpan di samping kunci pada <key>.contacts.json, mode 0600. Memo dibawa di dalam amplop catatan (Catatan).
Tidak ada rand balance <address> dan tidak ada RPC saldo: chain tidak dapat menjawabnya untuk siapa pun. Sebuah wallet menghitung saldonya dengan memindai setiap amplop di chain menggunakan viewing key-nya (Catatan).
Kunci yang dapat Anda serahkan kepada orang lain
Pengungkapan adalah properti dari kunci, dan chain tidak dapat memaksakan satu pun darinya.
| kunci | membuka | granularitas |
|---|---|---|
viewing key nk (64 hex) | setiap catatan yang pernah diterima wallet dan, melalui ovk, setiap catatan yang pernah dikirimnya, beserta nullifier dari setiap pengeluaran | semua atau tidak sama sekali, berlaku surut dan ke depan |
kunci transaksi TxKey (32 byte) | tepat satu amplop yang disegelnya: catatan tersebut dan, sejak chain 18, memonya | satu pembayaran |
kunci panggilan K_call | transkrip input privat dari satu panggilan rahasia | satu panggilan |
Viewing key tidak dapat membelanjakan. Sejak chain 17 (otorisasi terpisah) bukti bundle itu sendiri dibuat dari nk, dan setiap bundle juga membawa bukti auth kedua yang kecil, yang hanya dapat dibuat oleh spend key dan yang terikat pada satu transaksi tersebut (Catatan). Itulah yang memungkinkan seorang pembukti (prover) yang didelegasikan diberi nk, dan dengan demikian seluruh riwayat wallet, tanpa dapat membelanjakan; wallet selalu membuat bukti auth di mesinnya sendiri. Alamat, kunci, dan catatan yang ada tidak berubah oleh pemisahan ini. Wallet menurunkan nk pada setiap eksekusi dan tidak pernah menyimpannya; setiap TxKey diambil baru untuk setiap amplop dan dibuang setelah penyegelan. Sebuah node dapat diberi viewing key melalui rand_importViewingKey (di memori, paling banyak 64 per node, hilang saat restart) sehingga ia memindai atas nama pemegangnya — jalur yang dipakai explorer — dan rand_checkTransaction(hash, key) memeriksa satu pembayaran terhadap sebuah TxKey dalam satu panggilan tanpa state. rand viewing-key mencetak nk, dan rand tx-key <hash> mencetak kunci dari setiap output transaksi yang dapat dibuka wallet ini.
Id token bukan alamat
Token RPL memiliki jenis ketiga dari pengenal teks, dan pengenal itu menamai sebuah token, tidak pernah seorang pemegang. Id aset 32 byte milik token ditampilkan sebagai 64 karakter hex dan sebagai rpl1…: bech32m (BIP-350) dengan human-readable part rpl atas 32 byte id, 52 karakter data ditambah checksum 6 karakter, 62 karakter. Penguraiannya ketat: checksum yang salah, human-readable part yang lain, payload yang tidak tepat 32 byte, atau huruf besar dan kecil yang bercampur akan ditolak, sehingga salah ketik tidak pernah teresolusi ke token yang berbeda. Sebuah catatan tidak membawa id; kata asset-nya adalah indeks registri padat milik token (Token RPL).
Penerima bridge
Format wire bridge memiliki slot penerima 32 byte, dan alamat terlindung tidak muat di dalamnya. Saat ini slot tersebut membawa hash dari alamat:
recipient_hash = blake3("rand-shielded-recipient" || pk_bytes || kem_ek)Penyetor di chain sumber menyebutkan hash tersebut, para guardian menandatanganinya, dan transaksi BridgeAttest membawa alamat lengkap agar ledger dapat memeriksanya terhadap hash itu (Bridge).
Alamat terlindung pendek: dicoba pada chain 11, dikembalikan
Chain 11 (tag fullnode v0.2, 2026-09-17) mengganti alamat panjang dengan receiver id sepanjang 53 hingga 55 karakter, rand1 + base58(blake3(receiver signing key) ‖ checksum), dan memindahkan kunci enkapsulasi ML-KEM ke dalam receiver record bertanda tangan yang diambil pengirim dari registri explorer atau diterima secara inline dalam permintaan pembayaran. Desain ini berjalan selama sehari dan dikembalikan pada hari yang sama (fullnode 17db41d); chain 12 kembali ke alamat panjang, persis seperti yang dijelaskan di atas, dan setiap chain sesudahnya, termasuk chain 20, tetap mempertahankannya.
Alasan pencabutannya. Receiver id adalah sebuah hash, dan pengirim tidak dapat menyegel note ke sebuah hash. Pembayaran pertama ke dompet yang belum pernah terdaftar mengharuskan penerima menyerahkan permintaan pembayaran atau berkas record, dan pendaftaran itu sendiri dibayar dengan transfer ke diri sendiri, yang tidak dapat dilakukan oleh dompet baru yang kosong. Kedua jalur penyampaian itu juga memberi tahu registri siapa yang akan menerima pembayaran. Desain yang mempertahankan alamat pendek, kemampuan menerima tanpa syarat, dan privasi kriptografis adalah alamat hibrida: kunci X25519 32-byte secara inline (sekitar 93 karakter), kunci pascakuantum melalui pencarian, dengan pembayaran pertama ke dompet yang belum terdaftar bersifat rahasia terhadap musuh klasik dan setiap pembayaran berikutnya sepenuhnya pascakuantum. Hal itu dispesifikasikan berikutnya; sampai desain tersebut dirilis, alamat panjang adalah alamat yang berlaku.
Spesifikasi chain 11 beserta implementasinya tetap berada dalam riwayat fullnode (docs/superpowers/specs/2026-09-17-short-shielded-address.md, tag v0.2) untuk bagian-bagian yang digunakan ulang oleh desain hibrida: kunci penandatangan penerima turunan, record bertanda tangan beserta verifier-nya, dan registri sebagai state chain.