Memahami shielded pool, Unified Address dan viewing key Zcash

Pool dalam Zcash bukan bursa atau syarikat yang menyimpan deposit pengguna; ia ialah keadaan nilai yang tertakluk pada peraturan konsensus tertentu. Pool telus menggunakan UTXO awam. Pembaca rantaian boleh melihat output yang diwujudkan, transaksi kemudian yang membelanjakannya dan jumlah yang dipaparkan. Alamat tidak dengan sendirinya mendedahkan identiti undang-undang, tetapi rekod awam menunjukkan penggunaan alamat serta hubungan aliran nilai.

Shielded pool mewakili nilai dengan note dan bukannya UTXO yang kelihatan. Rangkaian merekodkan data note tersulit, pepohon commitment dan semakan baki pool. Bukti membolehkan konsensus menyemak kesahan, pemeliharaan nilai dan pencegahan perbelanjaan berganda tanpa mendedahkan penerima serta jumlah note kepada pemerhati biasa seperti output telus. Spesifikasi Protokol Zcash menerangkan kedua-dua bentuk.

Sapling dan Orchard ialah shielded pool berasingan dengan protokol dan pepohon commitment note yang berlainan; bakinya bukan satu keadaan yang boleh saling menggantikan. Sprout ialah protokol shielded pertama Zcash. Selepas ZIP 211 diaktifkan, nilai baharu tidak lagi boleh dimasukkan ke dalam pool Sprout, walaupun transaksi Sprout lama kekal dalam sejarah rantaian.

Status rangkaian perlu dinyatakan mengikut tarikh. Indeks ZIP rasmi menyebut NU6.2 sebagai naik taraf Mainnet terkini yang selesai, diaktifkan pada blok 3,364,600 pada 3 Jun 2026. NU6.2 mengaktifkan semula tindakan Orchard selepas mitigasi kerentanan sementara dengan peraturan circuit yang dibetulkan. NU6.3 dan pool Ironwood masih cadangan draf, bukannya peraturan Mainnet semasa. Lihat ZIP 257, indeks ZIP dan draf ZIP 258.

Shielded note menghubungkan nilai dalam pool dengan kuasa penerima untuk membelanjakannya. Nilai, butiran penerima dan memo disulitkan supaya dompet dengan maklumat penerimaan yang betul boleh membacanya. Rantaian menyimpan data tersulit dan commitment kepada note, bukannya teks asalnya. Commitment membolehkan semakan tanpa mendedahkan kandungan note.

Apabila note dibelanjakan, transaksi mendedahkan nullifier yang sepadan. Pembelanja membuktikan bahawa dia mengetahui note itu dan menerbitkan nullifier; rangkaian menyemak bahawa nullifier tersebut belum pernah digunakan. Pemerhati boleh melihat nullifier dan pepohon commitment, tetapi tidak sepatutnya mengetahui commitment terdahulu yang sepadan dengannya. Ini mencegah perbelanjaan berganda tanpa merahsiakan semua data konsensus. Sapling dan Orchard berkongsi reka bentuk umum ini dengan kriptografi dan bukti yang berbeza; perbelanjaan tetap memerlukan kuasa peribadi yang sepadan.

Unified Address (UA) ialah satu rentetan berkod yang boleh mengandungi receiver Orchard, Sapling, P2SH telus dan P2PKH telus. Revision 0 yang aktif mesti mengandungi sekurang-kurangnya satu receiver shielded. Rentetan ini sengaja tidak boleh ditafsir secara visual, jadi jenis receiver di dalamnya tidak dapat dikenal pasti hanya dengan melihatnya. ZIP 316 membezakan Revision 0 daripada Revision 2 yang dicadangkan.

Dompet penghantar tidak membayar kepada semua receiver. Dalam Revision 0, susunan keutamaan ialah Orchard, Sapling, P2SH telus, kemudian P2PKH telus. Penghantar mesti menggunakan receiver berkeutamaan tertinggi yang disokong oleh dompet. Jika dompet menyokong Orchard, ia memilih Orchard; jika tidak menyokong Orchard tetapi menyokong Sapling, ia boleh memilih Sapling. Oleh itu, pool sebenar bergantung pada keupayaan dompet penghantar, bukan rentetan alamat yang dipaparkan sahaja.

Draf Revision 2 mencadangkan awalan zu untuk alamat shielded sahaja dan tu bagi format yang boleh merangkumi receiver telus. Indeks ZIP rasmi masih menandakan Revision 2 sebagai draf; jangan anggap awalan itu format UA Mainnet biasa yang sedang digunakan. Sebelum menghantar, semak jenis alamat, rangkaian yang dipilih dan receiver dalam pratonton dompet.

Pemindahan telus-ke-shielded (t→z) boleh membelanjakan UTXO awam dan mewujudkan note Sapling atau Orchard. Pemerhati rantaian boleh melihat input telus, perubahan pada pool telus dan nilai bersih yang masuk ke pool shielded. Namun, pemerhati tidak melihat alamat penerima shielded biasa atau jumlah setiap note seperti UTXO telus. Proses shielding masih meninggalkan maklumat di sempadan pool.

Dalam pemindahan sebaliknya (z→t), alamat dan jumlah output telus adalah awam, dan perubahan nilai berkaitan pada pool shielded boleh diperhatikan. Bayaran shielded yang mewujudkan note dalam satu pool mungkin menyembunyikan penerima dan jumlah; pemindahan antara Sapling dan Orchard boleh menjadikan perubahan baki setiap pool lebih bermaklumat. Nilai sempadan awam sahaja tidak mengenal pasti seseorang atau note lama, tetapi boleh dibandingkan dengan jumlah, masa dan rekod luar.

Jangan hanya bertanya sama ada alamat itu shielded; semak juga dari mana nilai itu bermula dan pool yang dilaluinya. Pengeluaran bursa, bayaran kepada peniaga atau pemindahan peribadi dengan jumlah atau masa yang diketahui boleh dibandingkan dengan maklumat sempadan awam. Ini tidak mendedahkan setiap pemilik note atau laluan dalaman secara automatik, tetapi boleh mengecilkan pilihan.

ZIP 316 mentakrifkan viewing key sebagai maklumat yang diperlukan untuk melihat bayaran ke alamat. Full Viewing Key (FVK) juga boleh memaparkan maklumat bayaran dari alamat itu. Incoming Viewing Key (IVK) boleh diterbitkan daripada FVK, dan alamat boleh diterbitkan daripada IVK. Unified Viewing Key menggabungkan item viewing key untuk berbilang protokol.

Viewing key sahaja tidak boleh menandatangani perbelanjaan; spending key berasingan atau sistem tandatangan diperlukan. Namun, viewing key bukan maklumat awam yang tidak berbahaya. Jenis key dan pelaksanaan dompet menentukan transaksi yang boleh dilihat; key peringkat akaun boleh mendedahkan lebih daripada satu alamat penerimaan. Sebelum berkongsi dengan juruaudit atau perkhidmatan, semak skop, tempoh penyimpanan, pilihan pemadaman dan sama ada key itu digabungkan dengan alamat lain.

Viewing key tidak menghapuskan petunjuk yang memang sudah terbuka: input dan output telus, jumlah serta masa boleh dianalisis tanpanya. Sebaliknya, explorer atau dompet yang tidak menyokong pool berkaitan mungkin tidak memaparkan transaksi shielded yang telah direkodkan pada rantaian. “Aplikasi tidak memaparkannya” tidak bermaksud “ia tiada pada rantaian”.

Keterlihatan bergantung pada pool dan jenis receiver. Aliran yang sepenuhnya telus mendedahkan alamat, jumlah dan hubungan UTXO. Bayaran shielded menyulitkan penerima dan nilai note, tetapi commitment, nullifier, masa dan data protokol tetap muncul pada rantaian. Peralihan pool, sokongan pool dompet, masa bayaran yang diketahui, rekod bursa dan viewing key yang dikongsi masing-masing boleh menjadi petunjuk.

Unified Address tidak memaksa setiap bayaran menggunakan Orchard. Receiver yang dipilih mungkin bergantung pada versi dompet, tetapan, pelaksanaan dan laluan transaksi. Semak pratonton atau hasil transaksi, bukan membuat andaian privasi hanya dengan menampal alamat. [Panduan privasi Monero](/ms/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) menerangkan reka bentuk lain; [panduan penggunaan semula alamat Bitcoin](/ms/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) membandingkannya dengan lejar telus.

Privasi rangkaian ialah lapisan lain. Penyedia RPC, pelayan light-wallet, bursa atau perkhidmatan pembayaran boleh melihat permintaan penciptaan atau penghantaran transaksi dan menyimpan alamat IP, akaun atau masa di luar rantaian. Bukti kriptografi tidak memadam log perkhidmatan secara automatik. Daripada mendakwa tahap tanpa nama mutlak, kenal pasti pihak yang menerima metadata dan cara ia disimpan.

Mula-mula pastikan dompet disambungkan ke Mainnet atau Testnet yang dimaksudkan. Semasa menyemak bayaran, pastikan penerima memberikan Unified Address dan lihat receiver yang akan dipilih oleh dompet. Rentetan UA tidak menunjukkan jenis receiver secara visual; semak pool, jumlah, memo dan yuran dalam dompet. Jika penerima meminta bayaran shielded tetapi pratonton menunjukkan output telus, semak sokongan protokol dalam kedua-dua dompet sebelum menghantar.

Untuk menyiasat transaksi sedia ada, padankan ID transaksi dan rangkaiannya, kemudian semak pool yang muncul pada input dan output. Alamat dan jumlah telus boleh dilihat pada explorer awam; butiran note mungkin tiada pada alat yang tidak menyokongnya. Jika viewing key diperlukan, tentukan sebab dan maklumat yang didedahkannya; jangan tampal spending key atau viewing key ke laman yang tidak dikenali. Panduan dompet kustodian dan bukan kustodian turut menerangkan tanggungjawab tandatangan.

Jangan simpulkan “saya guna alamat shielded, jadi bayaran ini sepenuhnya peribadi” atau “explorer tidak menunjukkan nilai, jadi pemindahan tidak berlaku”. Sejarah dompet, rangkaian, ID transaksi, status rantaian, pengesahan dan kuasa viewing ialah fakta berbeza. Jika penerima perlu mengesahkan penerimaan, semak juga sama ada dompetnya menyokong dan telah menyegerakkan pool yang berkaitan.

Katakan Lee menghantar 1.25 ZEC daripada UTXO telus ke Unified Address Revision 0 yang mengandungi receiver Orchard, Sapling dan telus. Jumlah ini sekadar ilustrasi; ia bukan kadar yuran atau tetapan lalai dompet. Jika dompet Lee menyokong Orchard, peraturan keutamaan ZIP 316 memilih receiver Orchard. Rantaian awam menunjukkan input telus dan maklumat sempadan seperti nilai bersih yang masuk ke pool shielded, tetapi bukan alamat shielded note dan jumlahnya sebagai output awam biasa.

Jika dompet Lee tidak menyokong Orchard tetapi menyokong Sapling, ia boleh memilih Sapling. Dompet yang tidak menyokong mana-mana pool shielded boleh menggunakan receiver telus jika receiver dan format bayaran itu tersedia. Revision 0 UA mesti mengandungi receiver shielded, tetapi penghantar hanya memilih receiver yang disokong dompetnya. Oleh itu, UA yang sama boleh menghasilkan pool dan maklumat sempadan awam berlainan pada dompet dengan keupayaan berbeza.

Akhir sekali, jika penerima berkongsi viewing key secara berasingan dengan perkhidmatan perakaunan, perkhidmatan itu mungkin melihat aktiviti shielded dalam skop key tersebut. Paparan penerimaan dalam dompet, butiran note yang tidak dipaparkan oleh explorer dan rekod transaksi pada rantaian mengikut konsensus ialah tiga fakta berbeza. Unified Address memudahkan keserasian antara generasi protokol, tetapi tidak menjamin privasi penuh atau menggantikan pemilihan receiver, pengurusan key dan tanggungjawab pendedahan rangkaian.

• Zcash Protocol Specification v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Disabling New Value to the Sprout Pool
• ZIP 257: NU6.2 and the Orchard Temporary Mitigation
• ZIP 258: Draft NU6.3 Deployment
• Indeks ZIP rasmi: status Mainnet dan status cadangan