Yazar: Vitalik Buterin
Çeviri ve Derleme: DeFi Yolu
Geri bildirim ve incelemeleri için Ben DiFrancesco, Matt Solomon, Toni Wahrstätter ve Antonio Sanso’ya teşekkür ederiz.
Ethereum ekosistemindeki en büyük zorluklardan biri gizliliktir. Varsayılan olarak, herhangi bir şeyin genel bir blokzincire kaydedilmesi, herkes tarafından görülebileceği anlamına gelir. Bu durum giderek yalnızca para ve finans işlemlerini değil, aynı zamanda ENS alan adlarını, POAP’leri, NFT’leri ve ruh bağlamalı tokenları (soulbound tokens) da kapsıyor. Pratikte, Ethereum’un sunduğu tüm uygulamaları kullanmak, yaşamınızın önemli bölümlerini herkesin görüntüleyip analiz edebileceği şekilde açık etmeyi gerektiriyor.
Bu durumu nasıl iyileştireceğimiz sorusu, geniş çapta kabul gören önemli bir konudur. Ancak şu ana kadar gizliliği artırma tartışmaları çoğunlukla tek bir kullanım senaryosu etrafında dönmüştür: ETH ve popüler ERC-20 token’larının gizli transferi (genellikle kendi kendine transfer). Bu makale, Ethereum’daki gizlilik durumunu birçok farklı senaryoda iyileştirebilecek bir araç sınıfının mekanizmalarını ve kullanım alanlarını ele alacak: gizli adresler (stealth addresses).
Gizli Adres Sistemi Nedir?
Diyelim ki Alice, Bob’a bir varlık göndermek istiyor. Bu, bir miktar kriptopara (örneğin 1 ETH veya 500 RAI) veya bir NFT olabilir. Bob bu varlığı aldığında, dünyanın geri kalanının onun alıcı olduğunu bilmesini istemiyor. Bir işlemin gerçekleştiğini gizlemek imkânsız olabilir, özellikle de bu işlem zincirde tek kopyası bulunan bir NFT ise; ancak kimin alıcı olduğunu gizlemek daha gerçekçi bir hedeftir. Alice ve Bob aynı zamanda pratik bir çözüm arıyor: Ödeme sürecinin bugünkü gibi basit kalmasını istiyorlar. Bob, Alice’e (veya ENS kaydı üzerinden) kendisine ödeme yapılmasını sağlayan bir “adres” kodu gönderir; bu bilgi, Alice’in (veya başka birinin) ona varlık göndermesi için yeterlidir.
Bunun, Tornado Cash gibi araçlarla sağlanan gizlilikten farklı olduğunu belirtmek gerekir. Tornado Cash, ETH veya popüler ERC-20 token’ları gibi standart değiştirilebilir varlıkların transferini gizleyebilir (en kolay şekilde kendi kendine gizli gönderimler için kullanılır); ancak bilinmeyen ERC-20 transferlerine gizlilik eklemekte yetersiz kalır ve NFT transferlerine hiç gizlilik sağlayamaz.
Kripto para ile ödeme yapmanın standart iş akışı. Amacımız gizliliği artırmak (kimse Bob’un varlığı aldığını bilmeyecek) ancak iş akışını aynı tutmak.
Gizli adresler tam da böyle bir çözüm sunar. Gizli adresler, Alice veya Bob tarafından oluşturulabilen ancak yalnızca Bob tarafından kontrol edilebilen adreslerdir. Bob gizli bir harcama anahtarı oluşturur ve bunu saklar; ardından bu anahtarla bir gizli meta-adres üretir. Bu meta-adresi Alice’e (veya ENS üzerinden) gönderir. Alice, bu meta-adrese belirli hesaplamalar uygulayarak Bob’a özel bir gizli adres oluşturabilir. Daha sonra göndermek istediği herhangi bir varlığı bu adrese yollayabilir; Bob bu varlıkların tam kontrolüne sahip olacaktır. İşlem sırasında Alice, zincir üzerinde Bob’un bu adresin kendisine ait olduğunu anlamasına yardımcı olacak ek bir şifreli veri (geçici bir genel anahtar) yayınlar.
Başka bir deyişle: Gizli adresler, her işlem için yeni bir adres oluşturarak Bob’a aynı gizlilik avantajını sağlar; ancak bu süreçte Bob’un herhangi bir müdahalesi gerekmez.
Gizli adres şemasının tam iş akışı aşağıda gösterilmektedir:
1. Bob, kök harcama anahtarını (m) ve görünmez meta adresini (M) oluşturur.
2. Bob, M'yi bob.eth'in görünmez meta adresi olarak kaydetmek için bir ENS kaydı ekler.
3. Alice'in Bob'un bob.eth olduğunu bildiğini varsayalım. Alice, onun görünmez meta adresini (M) bulmak için ENS'de arama yapar.
4. Alice, yalnızca kendisinin bildiği ve yalnızca bir kez kullanacağı (bu özel görünmez adresi oluşturmak için) geçici bir anahtar üretir.
5. Alice, geçici anahtarını ve Bob'un meta adresini birleştirerek bir görünmez adres üreten bir algoritma kullanır. Artık bu adrese varlık gönderebilir.
6. Alice ayrıca geçici ortak anahtarını üretir ve bunu geçici ortak anahtar kayıt defterine yayınlar (bu işlem, varlıkları bu görünmez adrese gönderen ilk işlemle aynı anda gerçekleştirilebilir).
7. Bob'un kendisine ait görünmez adresleri keşfetmesi için, geçici ortak anahtar kayıt defterini taraması gerekir. Bu tarama, son taramasından bu yana herhangi bir nedenle yayınlanmış tüm geçici ortak anahtarların listesini içerir.
8. Her geçici ortak anahtar için Bob, bunu kendi kök harcama anahtarıyla birleştirerek bir görünmez adres üretmeye çalışır ve bu adreste herhangi bir varlık olup olmadığını kontrol eder. Eğer varsa, Bob bu adresin harcama anahtarını hesaplar ve kaydeder.
Tüm bu süreç, kriptografik bir ilkeye iki aşamada başvurur. İlk olarak, paylaşılan bir gizli anahtar üretmek için bir algoritma çiftine ihtiyacımız vardır: biri Alice'in gizli öğesiyle (geçici anahtarı) ve Bob'un açık öğesiyle (meta adresi), diğeri ise Bob'un gizli öğesiyle (kök harcama anahtarı) ve Alice'in açık öğesiyle (geçici ortak anahtarı). Bu, çeşitli şekillerde yapılabilir; modern kriptografinin temel taşlarından biri olan Diffie-Hellman anahtar değişimi, tam olarak bu işlevi yerine getirir.
Ancak yalnızca paylaşılan bir gizli anahtar yeterli değildir. Eğer paylaşılan gizli anahtardan doğrudan bir özel anahtar üretseydik, hem Alice hem de Bob bu adresten harcama yapabilirdi. Bu noktada durup Bob'un fonları yeni bir adrese aktarmasını sağlayabilirdik, ancak bu yöntem verimsizdir ve güvenlik düzeyini gereksiz yere düşürür. Bu yüzden bir anahtar körleme mekanizması da ekleriz: bir algoritma çifti, Bob'un paylaşılan gizli anahtarı ile kök harcama anahtarını birleştirerek ve Alice'in paylaşılan gizli anahtarı ile Bob'un meta adresini birleştirerek görünmez adresi oluşturmasını sağlar. Böylece Alice görünmez adresi oluşturabilir ve Bob da bu görünmez adres için harcama anahtarını üretebilir. Tüm bu işlemler, görünmez adres ile Bob'un meta adresi (ya da bir görünmez adres ile başka bir görünmez adres) arasında herhangi bir genel bağlantı oluşturmadan gerçekleşir.
Eliptik Eğri Kriptografisi ile Görünmez Adresler
Eliptik eğri kriptografisi (EKK) ile görünmez adresler, Peter Todd tarafından 2014 yılında Bitcoin bağlamında ilk kez tanıtıldı. Bu teknik şu şekilde çalışır (temel EKK bilgisi gerektirir; bazı öğreticiler için buraya, buraya ve buraya bakınız):
• Bob bir özel anahtar (m) üretir ve M = G * m'yi hesaplar; burada G, eliptik eğrinin önceden kabul edilmiş bir üreteç noktasıdır (generator point). Görünmez meta adres, M'nin kodlanmış halidir.
• Alice geçici bir özel anahtar (r) üretir ve geçici ortak anahtar R = G * r'yi yayınlar.
• Alice paylaşılan gizli anahtarı S = M * r şeklinde hesaplayabilirken, Bob aynı paylaşılan gizli anahtarı S = m * R şeklinde hesaplayabilir.
• Genellikle Bitcoin ve Ethereum'da (doğru tasarlanmış ERC-4337 hesapları dahil), adresler, o adresten yapılan işlemleri doğrulamak için kullanılan ortak anahtarın hash'idir. Dolayısıyla ortak anahtarı hesaplarsanız, adresi de hesaplayabilirsiniz. Ortak anahtarı hesaplamak için Alice ya da Bob, P = M + G * hash(S) formülünü kullanabilir.
• Bu adresin özel anahtarını hesaplamak için ise Bob (ve sadece Bob) p = m + hash(S) formülünü kullanabilir. Bu, yukarıda belirttiğimiz tüm gereksinimleri karşılar ve oldukça basittir!
Bugün bile Ethereum için bir görünmez adres standardı tanımlamayı amaçlayan bir EIP (Ethereum İyileştirme Teklifi) bulunmaktadır. Bu standart hem bu yöntemi desteklemekte hem de kullanıcıların diğer yöntemleri geliştirmelerine olanak tanımaktadır (örneğin, Bob'un ayrı harcama ve görüntüleme anahtarlarına sahip olması veya kuantum dirençli güvenlik sağlamak için farklı kriptografi kullanması gibi). Şimdi muhtemelen şöyle düşünüyorsunuz: "Görünmez adresler zor değil, teori sağlam, uygulama sadece bir detay." Ancak sorun, gerçekten etkili bir uygulamanın oldukça büyük uygulama detaylarını aşmayı gerektirmesidir.
Gizli Adresler ve İşlem Ücreti Sorunu
Birinin size bir NFT gönderdiğini düşünelim. Gizliliğinizi korumak için, bu NFT'yi sizin kontrolünüzdeki bir gizli adrese gönderirler. Cüzdanınız, zincirdeki geçici (ephemeral) genel anahtarı taradıktan sonra bu adresi otomatik olarak keşfeder. Artık bu NFT'nin sahipliğini kanıtlayabilir veya başkasına devredebilirsiniz. Ancak burada bir sorun var: Bu hesapta hiç ETH bulunmuyor, dolayısıyla işlem ücretleri ödenemez. ERC-4337 token ödemeleri bile işe yaramaz, çünkü bunlar yalnızca değiştirilebilir ERC-20 token'ları için geçerlidir. Üstelik, ETH'yi ana cüzdanınızdan bu adrese gönderemezsiniz; çünkü bu, aranızda açık bir bağlantı kurulmasına yol açar.
Bu sorunu çözmek için "basit" bir yöntem bulunuyor: İşlem ücretlerini ödemek için ZK-SNARK'lar aracılığıyla fon aktarmak! Ne var ki bu yöntem oldukça fazla gas tüketir; tek bir transfer için yüz binlerce ekstra gas harcanması gerekebilir.
Bir diğer akıllı çözüm ise özel işlem toplayıcılarına (MEV terminolojisinde "aramacılar" olarak bilinir) güvenmeyi içerir. Bu toplayıcılar, kullanıcıların zincir üzerindeki işlem ücretlerini ödemek için kullanılabilecek "bilet" adı verilen bir paket satın almak üzere tek seferlik ödeme yapmalarına olanak tanır. Kullanıcı, içinde başka hiçbir varlık bulunmayan bir gizli adresteki bir NFT'yi harcamak istediğinde, bu biletlerden birini Chaumian körlük (Chaumian blinding) şeması ile kodlanmış şekilde toplayıcıya sağlar. Bu protokol, 1980'ler ve 1990'larda önerilen merkeziyetsiz gizlilik odaklı elektronik nakit sistemlerinde kullanılan orijinal yöntemdir. Aramacılar "bilet"i kabul eder ve işlemi ücretsiz olarak kendi paketlerine dahil ederek, işlem başarıyla bir bloğa eklenene kadar bu süreci tekrarlar. Söz konusu miktar küçük olduğundan ve yalnızca işlem ücretlerini ödemek için kullanılacağından, bu merkeziyetsiz gizlilik odaklı elektronik nakit sisteminin "tam" uygulamasına kıyasla güven ve düzenleme sorunları çok daha azdır.
Gizli Adresler: Harcama ve Görüntüleme Anahtarlarının Ayrılması
Diyelim ki Bob'un her şeyi yapabilen tek bir "kök harcama anahtarı" yok. Bunun yerine, ayrı bir kök harcama anahtarı ve bir görüntüleme anahtarı kullanmak istiyor. Görüntüleme anahtarı, Bob'un tüm gizli adreslerini görmesini sağlar ancak bu adreslerden harcama yapmasına izin vermez.
Eliptik eğriler dünyasında bu sorun, oldukça basit bir kriptografik teknikle çözülebilir:
• Bob'un meta adresi M artık (K, V) biçimindedir ve G * k ile G * v olarak kodlanır; burada k harcama anahtarı, v ise görüntüleme anahtarıdır.
• Ortak gizli değer artık S = V * r = v * R şeklindedir; burada r hâlâ Alice'in geçici anahtarı, R ise Alice'in yayınladığı geçici genel anahtarıdır.
• Gizli adresin genel anahtarı P = K + G * hash(S), özel anahtarı ise p = k + hash(S) şeklindedir.
İlk akıllı kriptografik adım (ortak gizli değerin üretilmesi) görüntüleme anahtarını kullanırken, ikinci akıllı adım (Alice ve Bob'un paralel algoritmaları ile gizli adresin ve özel anahtarının üretilmesi) kök harcama anahtarını kullanır.
Bunun birçok kullanım alanı vardır. Örneğin, Bob bir POAP almak isterse, zinciri tarayıp tüm POAP'larını görüntülemek için görüntüleme anahtarını POAP cüzdanına (hatta daha az güvenli bir web arayüzüne) verebilir; ancak bu arayüzün POAP'ları harcamasına izin vermez.
Gizli Adresler ve Daha Kolay Tarama
Tüm geçici genel anahtar kümesini daha verimli taramak için kullanılan bir teknik, her geçici genel anahtarına bir görünüm etiketi (view tag) eklemektir. Yukarıdaki mekanizmada bunu gerçekleştirmenin bir yolu, görünüm etiketini ortak gizli değerin bir baytı olarak belirlemektir (örneğin, S mod 256'ya göre x koordinatı veya hash(S)'in ilk baytı).
Bu sayede Bob, ortak gizli değeri hesaplamak için her geçici genel anahtar için yalnızca bir eliptik eğri çarpma işlemi yapar; tam adresi üretmek ve doğrulamak için gereken daha karmaşık hesaplamaları ise yalnızca 1/256 oranında gerçekleştirir.
Gizli Adresler ve Kuantum Direnci
Yukarıdaki şema eliptik eğrilere dayanır; bu iyi bir şeydir ancak ne yazık ki kuantum bilgisayarlar karşısında savunmasızdır. Eğer kuantum bilgisayarlar pratik bir tehdit haline gelirse, kuantuma dayanıklı algoritmalara geçiş yapmamız gerekecektir. İki doğal aday bulunuyor: eliptik eğri izomorfizmaları (elliptic curve isogenies) ve ağlar (lattices).
Eğri izomorfizmi, eliptik eğriler üzerine kurulu, oldukça farklı bir matematiksel yapıdır. Yukarıda bahsedilen şifreleme tekniklerine benzer doğrusal özellikler kullanırken, kuantum bilgisayarların ayrık logaritma saldırılarına karşı savunmasız olabilecek döngüsel grupların oluşmasını akıllıca engeller.
İzomorfizm tabanlı kriptografinin temel zayıflığı, altında yatan matematiğin aşırı karmaşıklığı ve bu karmaşıklık içinde gizlenmiş olası saldırı riskidir. Geçen yıl bazı izomorfizm protokolleri kırılmış olsa da, diğerleri hâlâ güvenli durumda. Bu yöntemin başlıca avantajı ise nispeten küçük anahtar boyutları ve eliptik eğri tabanlı birçok tekniğin doğrudan uyarlanabilmesidir.
CSIDH içindeki 3-izomorfizminin kaynağı buradadır.
Kafesler (Lattices), eliptik eğri izomorfizminden çok daha basit bir matematiğe dayanan, oldukça güçlü işlevler (örneğin tam homomorfik şifreleme – FHE) gerçekleştirmeye olanak tanıyan farklı bir kriptografik yapıdır. Gizli adres şemaları kafesler üzerine inşa edilebilir; ancak en iyi şemayı tasarlamak hâlâ çözülmemiş bir problemdir. Bununla birlikte, kafes tabanlı yapılar genellikle daha büyük anahtar boyutlarına sahiptir.
Tam homomorfik şifreleme (FHE), kafeslerin bir uygulamasıdır. FHE ayrıca gizli adres protokollerine farklı şekillerde yardımcı olabilir: Örneğin, Bob'un görünüm anahtarını açığa çıkarmadan, tüm zincirdeki varlıkların gizli adreslerine sahip olup olmadığını kontrol etme işlemini dış kaynak kullanarak (outsourcing) yapmasına imkan tanıyabilir.
Üçüncü bir yöntem de, genel amaçlı siyah kutu ilkellerinden gizli adres şemaları oluşturmaktır. Bu ilkeller, başka nedenlerle de gerekli olan temel bileşenlerdir. Bu şemanın paylaşılan gizli anahtar üretimi kısmı, doğrudan bir anahtar değişim işlemine karşılık gelir ki bu da açık anahtar şifreleme sistemlerinin önemli bir parçasıdır. Daha zor olan kısım ise, Alice'in yalnızca gizli adresi (harcama anahtarını değil) üretmesini, Bob'un ise harcama anahtarını üretmesini sağlayan paralel bir algoritma geliştirmektir.
Ne yazık ki, gizli adres şemaları, bir açık anahtar şifreleme sistemi oluşturmak için gereken bileşenlerden daha basit bileşenlerle inşa edilemez. Bunun basit bir kanıtı vardır: Bir gizli adres şeması kullanarak bir açık anahtar şifreleme sistemi kurabilirsiniz. Alice, Bob'a bir mesaj şifrelemek isterse, N adet işlem gönderebilir; her işlem ya Bob'un bir gizli adresine ya da kendi gizli adreslerinden birine yönlendirilir. Bob, hangi işlemlerin kendisine ulaştığını görerek mesajı okuyabilir. Bu önemlidir, çünkü matematiksel olarak açık anahtar şifrelemenin yalnızca hash fonksiyonlarıyla yapılamayacağı, oysa sıfır bilgi kanıtlarının yalnızca hash fonksiyonlarıyla yapılabileceği kanıtlanmıştır. Dolayısıyla, gizli adresler yalnızca hash fonksiyonlarıyla gerçekleştirilemez.
Nispeten basit bileşenler kullanan bir yöntem şudur: Sıfır bilgi kanıtları, hash fonksiyonları ve (anahtar gizleme için) açık anahtar şifreleme kullanılarak oluşturulabilir. Bob'un meta-adresi, genel bir şifreleme anahtarıyla birlikte bir hash değeri olan h = hash(x)'tir; harcama anahtarı ise karşılık gelen şifre çözme anahtarı olan x değeridir. Bir gizli adres oluşturmak için Alice bir c değeri üretir ve Bob'un okuyabileceği şekilde c'yi şifreleyerek geçici genel anahtarını yayınlar. Adresin kendisi, işlem sağlayıcısına x ve c değerlerinin sahipliğini kanıtlamak için sıfır bilgi kanıtı talep eden kod içeren bir ERC-4337 hesabıdır; bu kanıtta k = hash(hash(x), c) olur (burada k, hesap kodudur). x ve c değerlerini bilen Bob, adresi ve kodunu kendi başına yeniden oluşturabilir.
c'nin şifrelenmesi Bob'a veya başkalarına herhangi bir bilgi vermez ve k bir hash olduğu için c hakkında neredeyse hiçbir bilgi sızdırmaz. Cüzdan kodunun kendisi yalnızca k değerini içerir; c özel bir değerdir ve bu nedenle k, h'ye geri izlenemez.
Ancak bu yöntem bir STARK gerektirir ve STARK'lar oldukça büyüktür. Sonuç olarak, post-kuantum Ethereum dünyasında birçok uygulamanın pek çok STARK kullanacağına inanıyorum. Bu nedenle, tüm bu STARK'ları birbirine bağlayıp alan tasarrufu sağlamak amacıyla, burada açıklandığı gibi özyinelemeli bir STARK oluşturan toplama (aggregation) protokolleri öneriyorum.
Gizli Adresler, Sosyal Kurtarma ve Çoklu L2 Cüzdanlar
Uzun süredir sosyal kurtarma cüzdanlarının hayranıyım: Kurumlar, diğer cihazlarınız ve arkadaşlarınız arasında paylaşılan çoklu imza mekanizmasına sahip bu cüzdanlar, ana gizli anahtarınızı kaybetmediğiniz sürece, çoğunluk onayıyla hesabınıza erişiminizi geri kazanmanıza olanak tanır.
Ancak sosyal kurtarma cüzdanları, gizli adreslerle pek uyumlu değildir: Hesabınızı kurtarmanız gerektiğinde (yani onu kontrol eden gizli anahtarınızı değiştirmeniz gerektiğinde), aynı zamanda N adet gizli cüzdanınızın hesap doğrulama mantığını da değiştirmek için adımlar atmanız gerekir. Bu da N adet işlem gerektirir ve yüksek maliyet, kullanım kolaylığı kaybı ve gizlilik riskiyle sonuçlanır.
Sosyal kurtarma ve çoklu Layer 2 protokollerinin bir arada bulunduğu ortamda da benzer endişeler geçerlidir: Eğer Optimism, Arbitrum, Starknet, Scroll ve Polygon gibi zincirlerde hesaplarınız varsa ve ölçeklenebilirlik için bu rollup'larda onlarca paralel örnek bulunuyorsa, her birinde ayrı bir hesabınızın anahtarını değiştirmek son derece karmaşık bir hal alabilir.
Birden fazla zincirdeki onlarca hesabın anahtarlarını değiştirmek büyük bir çaba gerektirir.
Bir yaklaşım, kurtarma işlemlerinin nadiren gerçekleştiğini kabul edip bunların maliyetli ve zahmetli olmasını normal karşılamaktır. Belki de zaman bazlı bağlantıların geçerliliğini azaltmak için, varlıklarınızı iki haftalık bir sürede rastgele aralıklarla yeni gizli adreslere aktaran bir otomasyon yazılımı kullanabilirsiniz. Ancak bu yöntem ideal değildir. Bir diğer seçenek ise akıllı sözleşme tabanlı kurtarma yerine, vasi (guardian) ağı içinde kök anahtarın gizli paylaşımını kullanmaktır. Fakat bu durumda, vasi'nin hesabınızı kurtarma yetkisini iptal etme imkanınız ortadan kalkar; bu da uzun vadede risk oluşturur.
Daha karmaşık bir yöntem ise sıfır bilgi kanıtı (zero-knowledge proof – ZKP) kullanımını içerir. Yukarıdaki ZKP tabanlı şemayı ele alalım, ancak mantığını şöyle değiştirelim: Hesap, doğrudan k = hash(hash(x), c) değerini saklamak yerine, zincir üzerinde k'nin saklandığı konumu gizleyen bir taahhüt (commitment) tutar. Bu hesaptan ödeme yapmak için artık bir sıfır bilgi kanıtı sunmanız gerekir: (i) bu taahhüde karşılık gelen zincir üzerindeki konumu bildiğinizi ve (ii) bu konumdaki verinin bir k değeri içerdiğini (açıkça ifşa etmeden), ayrıca k = hash(hash(x), c) eşitliğini sağlayan x ve c değerlerine sahip olduğunuzu kanıtlamanız gerekir.
Bu yöntem, birçok hesabı —hatta çok sayıda Layer 2 protokolüne dağılmış olanları bile— tek bir k değeriyle (ana zincirde veya belirli bir Layer 2 üzerinde) merkezi olarak kontrol etmenizi sağlar. Böylece tek bir değeri değiştirmek, tüm hesapların sahipliğini değiştirmeye yeterli olurken, hesaplarınız arasındaki bağlantı da hiçbir şekilde açığa çıkmaz.
Sonuç
Temel "gizli adres" (stealth address) özelliği bugün nispeten hızlı bir şekilde hayata geçirilebilir ve Ethereum'daki gerçek kullanıcı gizliliğini önemli ölçüde artırabilir. Bunun için cüzdan tarafında bazı geliştirmeler yapılması gerekiyor. Ayrıca, diğer gizlilik nedenleriyle de cüzdanların yerel çoklu adres modeline doğru evrilmesi gerektiğini düşünüyorum (örneğin, etkileşime girdiğiniz her uygulama için yeni bir adres oluşturmak gibi).
Ancak gizli adresler, sosyal kurtarma gibi bazı uzun vadeli kullanılabilirlik sorunlarını da beraberinde getiriyor. Şu an için bu endişeleri kabullenmek mümkün; örneğin sosyal kurtarmanın gizliliği bir miktar azaltacağını veya kurtarma işlemlerinin varlıkları iki hafta boyunca yavaşça yeni adreslere taşımak için gecikmeye razı olmayı kabul edebilirsiniz (bu işlem üçüncü taraf hizmetlerle yönetilebilir). Uzun vadede bu sorunlar çözülebilir; ancak gizli adres ekosisteminin geleceği, uzun vadeli bakıldığında, büyük ölçüde sıfır bilgi kanıtlarına (ZKP'lere) bağlı görünüyor.