Zcash korumalı havuzları, Unified Address ve viewing key’ler

Zcash’te havuz, kullanıcı mevduatlarını tutan borsa veya şirket değil; belirli konsensüs kurallarına tabi bir değer durumudur. Şeffaf havuz herkese açık UTXO’lar kullanır. Zinciri inceleyen herkes hangi output’un oluşturulduğunu, sonraki hangi işlemin onu harcadığını ve görünen tutarı görebilir. Bir adres tek başına yasal kimliği göstermez, ancak herkese açık kayıt adres kullanımını ve değer akışları arasındaki bağlantıları ortaya koyabilir.

Korumalı havuzlar değeri görünür UTXO’lar yerine note’larla temsil eder. Ağ şifrelenmiş note verilerini, commitment ağaçlarını kaydeder ve havuz bakiyelerini denetler. Kanıtlar konsensüsün geçerliliği, değerin korunmasını ve çift harcamayı önlemeyi kontrol etmesini sağlar; sıradan gözlemci alıcıyı ve note tutarını şeffaf output’taki gibi okuyamaz. Zcash Protokol Belirtimi iki yapıyı da açıklar.

Sapling ve Orchard farklı protokollere ve note commitment ağaçlarına sahip ayrı korumalı havuzlardır; bakiyeleri tek bir değiştirilebilir durum değildir. Sprout, Zcash’in ilk korumalı protokolüydü. ZIP 211 etkinleştirildiğinden beri Sprout havuzuna yeni değer eklenemiyor, ancak eski Sprout işlemleri zincir geçmişinde kalıyor.

Ağ durumuna tarih ekleyin. Resmî ZIP dizini, Mainnet’te tamamlanan en son yükseltmenin 3 Haziran 2026’da 3.364.600 blok yüksekliğinde etkinleşen NU6.2 olduğunu belirtiyor. NU6.2, geçici bir güvenlik açığı önleminin ardından düzeltilmiş circuit kurallarıyla Orchard işlemlerini yeniden etkinleştirdi. NU6.3 ve Ironwood havuzu hâlâ taslak önerilerdir, mevcut Mainnet kuralları değildir. ZIP 257, ZIP dizini ve taslak ZIP 258 kaynaklarına bakın.

Korumalı note, bir havuzdaki değeri alıcının harcama yetkisine bağlar. Değer, alıcı bilgileri ve memo şifrelenir; böylece uygun alım bilgilerine sahip cüzdan bunları çözebilir. Zincir note’un açık metnini değil, şifreli veriyi ve note commitment’ını kaydeder. Commitment içeriği yayımlamadan doğrulama yapılmasını sağlar.

Note harcandığında işlem buna karşılık gelen bir nullifier’ı açıklar. Harcayan, note’u bildiğini kanıtlar ve nullifier’ı yayımlar; ağ daha önce kullanılıp kullanılmadığını denetler. Gözlemciler nullifier’ı ve commitment ağacını görür, ancak nullifier’ın hangi eski commitment’a ait olduğunu belirleyememelidir. Bu yapı tüm konsensüs verilerini gizlemeden çift harcamayı önler. Sapling ve Orchard bu genel tasarımı farklı kriptografi ve kanıtlarla uygular; harcama için ilgili özel yetki gerekir.

Unified Address (UA), Orchard, Sapling, şeffaf P2SH ve şeffaf P2PKH receiver’larını içerebilen tek bir kodlanmış dizgedir. Etkin Revision 0 biçiminde en az bir korumalı receiver bulunmalıdır. Dizge kasıtlı olarak opaktır; içerdiği receiver’lar yalnızca görünüşünden anlaşılamaz. ZIP 316, etkin Revision 0 ile önerilen Revision 2 biçimini ayırır.

Gönderen cüzdan tüm receiver’lara ödeme yapmaz. Revision 0’da tercih sırası Orchard, Sapling, şeffaf P2SH ve son olarak şeffaf P2PKH’dir. Gönderen, cüzdanın desteklediği en yüksek öncelikli receiver’ı kullanmalıdır. Cüzdan Orchard’ı destekliyorsa onu seçer; Orchard’ı desteklemiyor fakat Sapling’i destekliyorsa Sapling’i seçebilir. Bu nedenle kullanılan havuz, yalnızca görüntülenen adrese değil gönderen cüzdanın yeteneklerine bağlıdır.

Revision 2 taslağı, yalnızca korumalı adresler için zu ve şeffaf receiver içerebilen biçimler için tu öneklerini önerir. Resmî ZIP dizini Revision 2’yi hâlâ taslak olarak işaretliyor; bu önekleri yaygın, canlı Mainnet UA biçimi gibi sunmayın. Göndermeden önce cüzdan önizlemesinde adres türünü, ağı ve seçilen receiver’ı kontrol edin.

Şeffaftan korumalı havuza transfer (t→z), herkese açık UTXO’ları harcayıp Sapling veya Orchard note’ları oluşturabilir. Zincir gözlemcisi şeffaf girdileri, şeffaf havuzdaki değişiklikleri ve korumalı havuza giren net değeri görebilir. Ancak sıradan korumalı alıcı adresini ve note tutarlarını şeffaf UTXO gibi okuyamaz. Değeri korumalı havuza aktarmak sınırda iz bırakır.

Ters yöndeki transferde (z→t) şeffaf output adresleri ve tutarları herkese açıktır; korumalı havuz değerindeki karşılık gelen değişiklik de gözlemlenebilir. Tek bir havuz içinde note oluşturan korumalı ödeme alıcıyı ve tutarı gizleyebilirken Sapling ile Orchard arasındaki geçiş havuz bazındaki bakiye değişimlerini anlamlı kılabilir. Herkese açık sınır değeri tek başına bir kişiyi veya eski note’u belirlemez, ancak tutar, zaman ve dış kayıtlarla karşılaştırılabilir.

Bu yüzden yalnızca adresin korumalı olup olmadığını değil, değerin nereden geldiğini ve hangi havuzlardan geçtiğini de sorun. Bir borsa çekimi, satıcı ödemesi veya zamanı ya da tutarı bilinen kişisel transfer, herkese açık sınır verileriyle karşılaştırılabilir. Bu her note sahibini veya iç rotayı otomatik olarak açığa çıkarmaz, ancak olasılıkları daraltabilir.

ZIP 316, viewing key’i bir adrese yapılan ödemeleri görmek için gereken bilgi olarak tanımlar. Full Viewing Key (FVK) bu adresten yapılan ödemelere ilişkin bilgileri de gösterebilir. FVK’den Incoming Viewing Key (IVK), IVK’den ise adres türetilebilir. Unified Viewing Key’ler birden fazla protokole ait viewing-key öğelerini bir araya getirir.

Viewing key tek başına harcamaya imza atamaz; bunun için ayrı bir spending key veya imza sistemi gerekir. Yine de viewing key zararsız, herkese açık bir bilgi değildir. Anahtar türü ve cüzdanın uygulaması hangi işlemlerin görülebileceğini belirler; hesap düzeyindeki bir anahtar tek alım adresinden fazlasını açığa çıkarabilir. Bir denetçiyle veya hizmetle paylaşmadan önce kapsamı, saklama süresini, silme seçeneklerini ve başka adreslerle birleştirilip birleştirilmediğini kontrol edin.

Viewing key önceden herkese açık olan ipuçlarını ortadan kaldırmaz: şeffaf girdiler, çıktılar, tutarlar ve zaman bilgileri anahtar olmadan da analiz edilebilir. Diğer yandan, gerekli havuz desteği olmayan bir explorer veya cüzdan, zincire kaydedilmiş korumalı işlemi göstermeyebilir. “Uygulama göstermiyor” ifadesi “zincirde yok” anlamına gelmez.

Görünürlük havuza ve receiver türüne bağlıdır. Tamamen şeffaf bir akış adresleri, tutarları ve UTXO bağlantılarını gösterir. Korumalı ödeme note alıcılarını ve değerlerini şifreler; ancak commitment’lar, nullifier’lar, zamanlama ve protokol verileri zincirde görünür kalır. Havuz geçişleri, cüzdanın desteklediği havuzlar, bilinen ödeme zamanı, borsa kayıtları ve paylaşılan viewing key’ler ayrı ipuçları oluşturabilir.

Unified Address her ödemeyi Orchard’a yönlendirmeyi zorunlu kılmaz. Seçilen receiver cüzdan sürümüne, ayarlara, uygulamaya ve işlem yoluna göre değişebilir. Bir adresi yapıştırıp gizlilik sonucu çıkarmak yerine önizlemeyi veya işlem sonucunu kontrol edin. [Monero gizlilik rehberi](/tr/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained) farklı bir tasarımı anlatır; [Bitcoin adresinin tekrar kullanılması rehberi](/tr/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained) şeffaf bir defterle karşılaştırır.

Ağ gizliliği ayrı bir katmandır. RPC sağlayıcısı, light-wallet sunucusu, borsa veya ödeme hizmeti işlem oluşturma ya da iletme isteklerini görebilir; IP, hesap veya zaman bilgisini zincir dışında saklayabilir. Kriptografik kanıtlar hizmet kayıtlarını kendiliğinden silmez. Mutlak anonimlik iddia etmek yerine metaveriyi kimin aldığını ve nasıl sakladığını belirleyin.

Önce cüzdanın amaçlanan Mainnet veya Testnet’e bağlı olduğunu doğrulayın. Ödeme incelemesinde alıcının Unified Address verdiğini ve cüzdanın hangi receiver’ı seçtiğini kontrol edin. UA dizgesi receiver türlerini görsel olarak göstermez; cüzdandaki havuz, tutar, memo ve ücret bilgilerini okuyun. Alıcı korumalı ödeme istediği hâlde önizleme şeffaf output gösteriyorsa göndermeden önce her iki cüzdanın protokol desteğini kontrol edin.

Mevcut bir işlemi incelemek için işlem kimliğini ve ağı eşleştirin, ardından girdilerde ve çıktılarda hangi havuzların bulunduğuna bakın. Şeffaf adresler ve tutarlar halka açık explorer’larda görünür; korumalı note ayrıntıları bu desteği sunmayan araçlarda gösterilmeyebilir. Viewing key gerekiyorsa nedenini ve neyi açığa çıkardığını belirleyin; spending key’i veya viewing key’i tanımadığınız bir siteye yapıştırmayın. Custodial ve non-custodial cüzdan rehberi imza sorumluluğunu da açıklar.

“Korumalı adres kullandım, ödeme tamamen gizli” veya “explorer tutarı göstermiyor, transfer gerçekleşmedi” sonucuna varmayın. Cüzdan geçmişi, ağ, işlem kimliği, zincir durumu, onay sayısı ve görüntüleme yetkisi farklı olgulardır. Alıcı ödemeyi doğrulayacaksa cüzdanının ilgili havuzu desteklediğini ve eşitlediğini de kontrol edin.

Lee’nin şeffaf bir UTXO’dan Orchard, Sapling ve şeffaf receiver’lar içeren Unified Address Revision 0’a 1,25 ZEC gönderdiğini varsayalım. Bu tutar yalnızca örnektir; ücret oranı veya cüzdan varsayılanı değildir. Lee’nin cüzdanı Orchard’ı destekliyorsa ZIP 316 tercih kuralı Orchard receiver’ı seçer. Halka açık zincir şeffaf girdiyi ve korumalı havuza giren net değer gibi sınır verilerini gösterir; ancak alıcının korumalı note adresi ile tutarını sıradan herkese açık output olarak göstermez.

Lee’nin cüzdanı Orchard’ı desteklemiyor ama Sapling’i destekliyorsa Sapling’i seçebilir. Hiçbir korumalı havuzu desteklemeyen cüzdan, receiver ve ödeme biçimi mevcutsa şeffaf receiver’ı kullanabilir. Revision 0 UA’da korumalı receiver bulunması gerekir, ancak gönderen yalnızca cüzdanının desteklediği receiver’ı seçer. Bu nedenle aynı UA, farklı yeteneklere sahip cüzdanlarda farklı havuzlara ve herkese açık sınır verilerine yol açabilir.

Son olarak, alıcı bir görüntüleme key’ini muhasebe hizmetiyle ayrıca paylaşırsa bu hizmet key’in kapsamındaki korumalı hareketleri görebilir. Cüzdandaki alındı bildirimi, explorer’da note ayrıntılarının görünmemesi ve işlemin konsensüse göre zincire kaydedilmesi üç farklı olgudur. Unified Address protokol nesilleri arasında uyumluluğu kolaylaştırır; ancak tam gizlilik garantisi vermez ve receiver seçimi, key yönetimi veya ağdaki veri görünürlüğü sorumluluklarını ortadan kaldırmaz.

• 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
• Resmî ZIP dizini: Mainnet ve tekliflerin durumu