İdeal Ethereum Cüzdanı'nın Vizyonu: Cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseliş
Ethereum temel altyapı yığınında Cüzdan katmanı çok önemlidir, ancak genellikle ana araştırmacılar ve geliştiriciler tarafından hafife alınmaktadır. Kullanıcıların Ethereum dünyasıyla etkileşimi için bir pencere olan Cüzdanın, merkeziyetsizlik, sansüre dayanıklılık, güvenlik ve gizlilik gibi özelliklere sahip olması gerekmektedir; böylece kullanıcılar Ethereum'un ve uygulamalarının sunduğu bu özelliklerin gerçek anlamda tadını çıkarabilirler.
Son zamanlarda Ethereum cüzdanları, kullanıcı deneyimi, güvenlik ve işlevsellik açısından önemli ilerlemeler kaydetti. Bu makalenin amacı, ideal bir Ethereum cüzdanının sahip olması gereken özellikler hakkında bazı görüşlerimi paylaşmaktır. Bu, eksiksiz bir liste değildir; daha çok kripto anarşist eğilimlerimi yansıtır, güvenlik ve gizliliğe odaklanır, kullanıcı deneyimi açısından belki de yeterince kapsamlı değildir. Ancak bence, yalnızca geri bildirimlere dayanarak kullanıcı deneyimini optimize etmek yerine, güvenlik ve gizlilik özelliklerine odaklanmak daha değerli olabilir.
cross-chain L2 işlem kullanıcı deneyimi
Şu anda, L2 kullanıcı deneyimini geliştirmek için giderek daha kapsamlı bir yol haritası mevcut, kısa ve uzun vadeli bölümler içeriyor. Burada, kısa vadede uygulanabilir fikirleri tartışacağım.
Temel düşünce şudur: (1) yerleşik cross-chain L2 gönderim fonksiyonu, (2) zincirine özel adresler ve ödeme talepleri. Cüzdan, kullanıcılara ERC taslak tarzında bir adres sunabilmelidir.
Kullanıcı bu formatta bir adres aldığında, sadece bunu cüzdanın "Alıcı" alanına yapıştırması ve "Gönder" butonuna tıklaması yeterlidir, cüzdan gönderimi otomatik olarak işlemelidir:
Hedef zincirde yeterli token varsa, doğrudan gönder.
Diğer zincirlerde gerekli olan tokenleri, cross-chain DEX protokolü ile gönderin.
Farklı türde tokenler varsa, DEX'te doğru türdeki token ile dönüştürdükten sonra ( göndermek için kullanıcının onayı gerekmektedir )
Dapp'in depozit isteği için ideal uygulama, dapp'in zincir spesifik ödeme talepleri göndermesine izin veren web3 API'sini genişletmektir. Cüzdan, getAvailableBalance talebini standartlaştırmalı ve kullanıcı varlıklarının varsayılan olarak hangi zincirlerde saklandığını dikkatlice düşünmelidir, böylece güvenlik ve transfer kolaylığı dengelenebilir.
Blockchain'a özgü ödeme talepleri, mobil cüzdanların taraması için QR kodlarına da yerleştirilebilir. Yüz yüze veya çevrimiçi ödeme senaryolarında, alıcının gönderdiği QR kodu veya API çağrısı "X blockchain üzerinde Y birim Z token istiyorum, referans ID W" anlamına gelir, cüzdan bu talebi karşılamak için istediği yöntemi seçebilir. Diğer bir seçenek, kullanıcı cüzdanının yetkilendirilmiş QR kodu veya URL içeren bir talep bağlantısı protokolü oluşturmasıdır; alıcı fonları çekmekten sorumludur.
gas ödemesi de ilgili bir konudur. Kullanıcı bir L2 üzerinde varlık aldığında ancak ETH yoksa, cüzdanın kullanıcıda ETH bulunan zincir üzerinde gaz ödemesi yapmak için otomatik olarak protokolü kullanabilmesi gerekir. Cüzdan, kullanıcının gelecekte bu L2 üzerinde daha fazla işlem yapacağını öngörüyorsa, gaz rezervi olarak belirli bir miktar ETH göndermek için DEX kullanabilir.
Hesap Güvenliği
Hesap güvenliğinin anahtarının, kullanıcıları hem cüzdan geliştiricilerinin siber saldırılarından veya kötü niyetli davranışlarından korumak, hem de kullanıcıların kendi hatalarının etkilerinden korumak olduğuna inanıyorum.
Uzun zamandır tercih ettiğim çözüm, katmanlı erişim kontrolüne sahip sosyal kurtarma ve çoklu imza cüzdanıdır. Kullanıcı hesaplarının iki anahtarı vardır: anahtar ve N adet gözetmen ( (N=5)). Anahtar, düşük değerli ve finansal olmayan işlemler için kullanılabilir. Çoğu gözetmenin gerçekleştirmesi gereken (1) yüksek değerli işlemler, hesabın tüm fonlarının gönderilmesi, (2) anahtarın değiştirilmesi veya herhangi bir gözetmenin değiştirilmesidir. Gerektiğinde, anahtarın zaman kilidi ile yüksek değerli işlemleri gerçekleştirmesine izin verilebilir.
Bu temel tasarım daha da genişletilebilir. Oturum anahtarları ve yetki mekanizmaları, farklı uygulamaların kullanım kolaylığı ve güvenlik arasında denge kurmasına olanak tanır. Farklı eşiklerde birden fazla zaman kilidi süresi ayarlamak gibi daha karmaşık bir koruyucu mimari, yasal hesapların kurtarılma başarısını maksimize ederken, hırsızlık riskini en aza indirmeye yardımcı olur.
Vasi seçimi için birkaç seçenek vardır:
Deneyimli kripto kullanıcıları, arkadaşlarının ve ailelerinin anahtarlarını seçebilir.
Kurumsal Gözetmen: İmza hizmeti sunan özel şirket, ek bilgi onayına ihtiyaç duyar.
Birden fazla kişisel cihaz (, örneğin telefon, bilgisayar, donanım cüzdanı ), ancak yeni kullanıcıların yönetimi ayarlaması zor olabilir.
Şifre yöneticisine dayalı bir çözüm, yerel veya bulut yedeklemesi yapılabilir, ancak yalnızca bunlara güvenmek kullanıcıların tüm varlıklarını korumak için yeterli değildir.
ZK paketli merkezi ID: zk-email, Anon Aadhaar gibi, merkezi ID'leri Ethereum adresine dönüştürebilir.
ZK ile paketlenmiş merkezi ID, yeni kullanıcılar için daha dostça. Cüzdan, kullanıcıların doğrudan e-posta adresini vasisi olarak belirlemesine izin veren basit bir entegrasyon UI'sı sunmalıdır ve buna bağlı olarak ilgili zk-email Ethereum adresini otomatik olarak oluşturmalıdır. İleri düzey kullanıcılar, oluşturulan adresin doğruluğunu doğrulayabilmelidir.
Yeni kullanıcılar için, cüzdan basit seçenekler sunabilir, örneğin zk-email tabanlı, yerel depolama anahtarı ve sağlayıcı yedek anahtarı içeren 2-of-3 çözümü. Kullanıcı deneyimi arttıkça veya varlıklar çoğaldıkça, daha fazla gözetmen eklemeleri önerilmelidir.
Uygulama içi cüzdan entegrasyonu kaçınılmazdır, ancak kullanıcıların tüm cüzdanları bir araya getirip erişim kontrolünü merkezi bir şekilde yönetebilmesi gerekir. Basit bir yöntem, kullanıcıların ana cüzdanı, tüm uygulama içi cüzdanların koruyucusu olarak ayarlamalarına izin veren hiyerarşik bir sistem kullanmaktır.
Kullanıcıları dolandırıcılıklardan ve diğer dış tehditlerden koruma
Hesap güvenliğinin yanı sıra, mevcut cüzdan sahte adresleri, kimlik avını, dolandırıcılığı vb. tanıma konusunda birçok çalışma yaptı. Ancak, birçok önlem hala oldukça ilkel; örneğin, yeni bir adrese token göndermeden önce, miktar ne olursa olsun, tıklayıp onaylama zorunluluğu. Bu, farklı tehdit kategorilerine yönelik sürekli iyileştirme gerektiriyor, kalıcı bir çözüm yok.
Gizlilik
Ethereum'un gizliliğine artık daha ciddi yaklaşma zamanı. ZK-SNARK teknolojisi oldukça gelişmiştir, arka kapıya bağlı olmayan gizlilik teknolojileri ( gibi gizlilik havuzları ) giderek olgunlaşmaktadır, ikincil altyapılar olan Waku ve ERC-4337 mempool'ları da kademeli olarak istikrara kavuşmaktadır. Ancak şu anda gizli transferler için kullanıcıların "gizlilik cüzdanı" indirmesi gerekmektedir, bu da zorluğu artırmakta ve kullanıcı sayısını azaltmaktadır. Çözüm, gizli transferleri doğrudan cüzdan içine entegre etmektir.
Basit bir uygulama, cüzdanın kullanıcının bazı varlıklarını "gizli bakiye" olarak gizlilik havuzunda saklamasıdır. Para transferi sırasında gizlilik havuzundan otomatik olarak çıkılır, fon alındığında otomatik olarak görünmez adres oluşturulur.
Ayrıca, cüzdan kullanıcıların katıldığı her uygulama için otomatik olarak yeni adresler oluşturabilir. Mevduatlar gizlilik havuzundan gelir, çekimler doğrudan gizlilik havuzuna gider. Bu, kullanıcıların farklı uygulamalardaki etkinliklerini birbirinden ayırmalarına olanak tanır.
Bu, yalnızca varlık transferi gizliliğini korumanın doğal bir yolu değil, aynı zamanda kimlik gizliliğini korumanın bir yoludur. Zincir üzerindeki kimlikler zaten mevcuttur, örneğin kimlik doğrulama uygulamaları, token tabanlı sohbetler vb. Bu ekosistemin de gizliliği korumasını istiyoruz, yani kullanıcıların zincir üzerindeki faaliyetleri tek bir yerde toplanmamalıdır: her proje ayrı ayrı saklanmalı, yalnızca kullanıcı cüzdanı tüm kanıtları aynı anda görebilmelidir. Her kullanıcı için çoklu hesapları destekleyen bir ekosistem bu hedefe ulaşılmasına yardımcı olur, zincir dışı kanıt protokolleri olan EAS ve Zupass da aynı şekilde.
Bu, Ethereum'un gizliliği için orta vadeli pragmatik bir vizyonu temsil ediyor. L1 ve L2'de gizlilik koruma transferlerini daha verimli ve güvenilir hale getirecek bazı işlevlerin eklenmesi mümkün olsa da, şu anda uygulanabilir. Bazı gizlilik savunucuları, yalnızca tamamen gizliliğin kabul edilebilir olduğunu düşünüyor, örneğin tüm EVM'yi şifrelemek gibi. Bu, ideal bir uzun vadeli sonuç olabilir, ancak programlama modelinde daha temel bir yeniden düşünmeyi gerektirir ve şu anda dağıtılabilir olgunluğa ulaşmamıştır. Yeterince büyük bir anonim grup elde etmek için varsayılan gizliliğe gerçekten ihtiyacımız var. Ancak, öncelikle (1) hesaplar arası transferlere, (2) kimlik ve ilgili kullanım durumlarına (, örneğin özel kanıt ) gibi, pragmatik ilk adım olarak odaklanmak daha kolaydır ve cüzdanlar hemen kullanılmaya başlanabilir.
Ethereum cüzdanı da veri cüzdanı olmalıdır
Herhangi bir geçerli gizlilik çözümü, kullanıcıların verilerini ödemeler, kimlik veya diğer kullanım durumları için çevrimdışı depolama gereksinimi doğurur. Modern gizlilik protokolleri bazen zincir üzerinde şifreli verileri saklar, tek bir özel anahtar ile şifre çözme kullanır. Bu risklidir, çünkü anahtar sızdırılırsa veya kuantum bilgisayarlar çalışır hale gelirse, tüm veriler açığa çıkar. Zincir dışı kanıtlar, zincir dışı veri depolama gereksinimini daha belirgin hale getirir.
Cüzdan sadece zincir üzerindeki erişim izinlerini depolamakla kalmaz, aynı zamanda kullanıcı özel verilerini de depolaması gerekir. Kripto olmayan dünya da bunu giderek daha fazla anlamaya başlıyor. Verilerin erişilebilirliği ve sızdırılmaya karşı korunması etrafında sağlam garantiler inşa etmemiz gerekiyor. Bu çözümleri üst üste koymak mümkün olabilir: Eğer N tane vekil varsa, bu N vekil arasında M-of-N gizli paylaşım kullanarak verileri depolayın. Veriler esasen koruması daha zor, çünkü birinin veri payını geri almak mümkün değil, ancak mümkün olduğunca güvenli merkeziyetsiz barındırma çözümleri önermeliyiz.
Güvenli Zincir Erişimi
Şu anda cüzdan, zincir bilgilerini almak için RPC sağlayıcısına bağımlıdır, bu iki açığın varlığını taşır:
RPC sağlayıcıları, piyasa fiyatı gibi yanlış bilgiler sağlayarak ( gibi fonları çalabilir.
RPC sağlayıcıları, kullanıcıların uygulamalarla etkileşimde bulunduğu özel bilgilere erişebilir.
İdeal olarak, bu iki açığı kapatmayı umuyoruz. İlk sorunun çözümü, L1 ve L2 için standart hafif istemciler gerektirir ve doğrudan blok zinciri konsensüsünü doğrular. Helios, L1 için bunu gerçekleştirmiştir ve bazı L2'leri desteklemeye başlamıştır. Tüm L2'leri kapsamak için, L2'yi temsil eden yapılandırma sözleşmesi aracılığıyla en son durum kökünü almak ve durum ve makbuz kanıtlarının mantığını doğrulamak için bir standart gereklidir. Bu şekilde, cüzdanın L1 ve L2 üzerindeki herhangi bir durum veya olayı güvenli bir şekilde doğrulamasını sağlayan evrensel bir hafif istemciye sahip olabiliriz.
Gizlilik için, şu anda tek gerçek yöntem kendi tam düğümünüzü çalıştırmaktır. Ancak L2'nin yaygınlaşmasıyla, her şeyi çalıştıran tam düğüm işletmek giderek daha zor hale geliyor. Buradaki hafif istemci eşdeğeri özel bilgi alma )PIR(. PIR, tüm veri kopyalarını saklayan sunucuları ve sunucuya şifreli talepler gönderen istemcileri içerir. Sunucu tüm veriler üzerinde hesaplamalar yapar, istemcinin ihtiyaç duyduğu şifreli verileri geri dönerken, istemcinin hangi verilere eriştiğini bilmez.
Sunucunun dürüstlüğünü sağlamak için, her bir veritabanı öğesi Merkle dalı olarak tasarlanmıştır, istemci hafif istemci ile doğrulama yapabilir.
PIR hesaplama miktarı çok büyük. Çözümler arasında şunlar bulunmaktadır:
Kaba kuvvet: Algoritma veya özel donanım iyileştirmeleri PIR'nin yeterince hızlı çalışmasını sağlayabilir.
Gizlilik gereksinimlerini azaltma: Her aramada yalnızca 1.000.000 "mixins".
Çoklu Sunucu PIR: Birden fazla sunucu kullanarak, 1-of-N'in dürüst olduğunu varsayarsak, PIR algoritması genellikle daha hızlıdır.
Anonimlik ve gizlilik: İstekleri karıştırma ağı üzerinden göndererek, göndericiyi gizler, içeriği değil. Ancak bu gecikmeyi artırır.
Ethereum ortamında gizliliği maksimize ederken pratikliği korumak için doğru teknik kombinasyonunu bulmak açık bir araştırma sorusudur.
![Vitalik yeni makale: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseltme])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
İdeal Anahtar Kasası Cüzdanı
cross-chain L2 bağlamında, başka bir sorunsuz çalışması gereken önemli süreç hesap doğrulamasını değiştirmektir.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
11 Likes
Reward
11
5
Share
Comment
0/400
OldLeekConfession
· 07-09 10:20
Gizlilik koruma geldi, beni de say.
View OriginalReply0
TooScaredToSell
· 07-07 17:07
Blok Zinciri'nde gizlilik çok önemlidir, doğru söylüyorsunuz.
View OriginalReply0
metaverse_hermit
· 07-07 01:17
Blok Zinciri güvenliği birinci sırada~
View OriginalReply0
GetRichLeek
· 07-07 01:09
Küçük Soğuk Cüzdan üç kez çalındı, hâlâ ders almıyor.
İdeal Ethereum Cüzdan Vizyonu: cross-chain deneyimi, gizlilik koruma ve güvenlik yükseltmesi
İdeal Ethereum Cüzdanı'nın Vizyonu: Cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseliş
Ethereum temel altyapı yığınında Cüzdan katmanı çok önemlidir, ancak genellikle ana araştırmacılar ve geliştiriciler tarafından hafife alınmaktadır. Kullanıcıların Ethereum dünyasıyla etkileşimi için bir pencere olan Cüzdanın, merkeziyetsizlik, sansüre dayanıklılık, güvenlik ve gizlilik gibi özelliklere sahip olması gerekmektedir; böylece kullanıcılar Ethereum'un ve uygulamalarının sunduğu bu özelliklerin gerçek anlamda tadını çıkarabilirler.
Son zamanlarda Ethereum cüzdanları, kullanıcı deneyimi, güvenlik ve işlevsellik açısından önemli ilerlemeler kaydetti. Bu makalenin amacı, ideal bir Ethereum cüzdanının sahip olması gereken özellikler hakkında bazı görüşlerimi paylaşmaktır. Bu, eksiksiz bir liste değildir; daha çok kripto anarşist eğilimlerimi yansıtır, güvenlik ve gizliliğe odaklanır, kullanıcı deneyimi açısından belki de yeterince kapsamlı değildir. Ancak bence, yalnızca geri bildirimlere dayanarak kullanıcı deneyimini optimize etmek yerine, güvenlik ve gizlilik özelliklerine odaklanmak daha değerli olabilir.
cross-chain L2 işlem kullanıcı deneyimi
Şu anda, L2 kullanıcı deneyimini geliştirmek için giderek daha kapsamlı bir yol haritası mevcut, kısa ve uzun vadeli bölümler içeriyor. Burada, kısa vadede uygulanabilir fikirleri tartışacağım.
Temel düşünce şudur: (1) yerleşik cross-chain L2 gönderim fonksiyonu, (2) zincirine özel adresler ve ödeme talepleri. Cüzdan, kullanıcılara ERC taslak tarzında bir adres sunabilmelidir.
Kullanıcı bu formatta bir adres aldığında, sadece bunu cüzdanın "Alıcı" alanına yapıştırması ve "Gönder" butonuna tıklaması yeterlidir, cüzdan gönderimi otomatik olarak işlemelidir:
Dapp'in depozit isteği için ideal uygulama, dapp'in zincir spesifik ödeme talepleri göndermesine izin veren web3 API'sini genişletmektir. Cüzdan, getAvailableBalance talebini standartlaştırmalı ve kullanıcı varlıklarının varsayılan olarak hangi zincirlerde saklandığını dikkatlice düşünmelidir, böylece güvenlik ve transfer kolaylığı dengelenebilir.
Blockchain'a özgü ödeme talepleri, mobil cüzdanların taraması için QR kodlarına da yerleştirilebilir. Yüz yüze veya çevrimiçi ödeme senaryolarında, alıcının gönderdiği QR kodu veya API çağrısı "X blockchain üzerinde Y birim Z token istiyorum, referans ID W" anlamına gelir, cüzdan bu talebi karşılamak için istediği yöntemi seçebilir. Diğer bir seçenek, kullanıcı cüzdanının yetkilendirilmiş QR kodu veya URL içeren bir talep bağlantısı protokolü oluşturmasıdır; alıcı fonları çekmekten sorumludur.
gas ödemesi de ilgili bir konudur. Kullanıcı bir L2 üzerinde varlık aldığında ancak ETH yoksa, cüzdanın kullanıcıda ETH bulunan zincir üzerinde gaz ödemesi yapmak için otomatik olarak protokolü kullanabilmesi gerekir. Cüzdan, kullanıcının gelecekte bu L2 üzerinde daha fazla işlem yapacağını öngörüyorsa, gaz rezervi olarak belirli bir miktar ETH göndermek için DEX kullanabilir.
Hesap Güvenliği
Hesap güvenliğinin anahtarının, kullanıcıları hem cüzdan geliştiricilerinin siber saldırılarından veya kötü niyetli davranışlarından korumak, hem de kullanıcıların kendi hatalarının etkilerinden korumak olduğuna inanıyorum.
Uzun zamandır tercih ettiğim çözüm, katmanlı erişim kontrolüne sahip sosyal kurtarma ve çoklu imza cüzdanıdır. Kullanıcı hesaplarının iki anahtarı vardır: anahtar ve N adet gözetmen ( (N=5)). Anahtar, düşük değerli ve finansal olmayan işlemler için kullanılabilir. Çoğu gözetmenin gerçekleştirmesi gereken (1) yüksek değerli işlemler, hesabın tüm fonlarının gönderilmesi, (2) anahtarın değiştirilmesi veya herhangi bir gözetmenin değiştirilmesidir. Gerektiğinde, anahtarın zaman kilidi ile yüksek değerli işlemleri gerçekleştirmesine izin verilebilir.
Bu temel tasarım daha da genişletilebilir. Oturum anahtarları ve yetki mekanizmaları, farklı uygulamaların kullanım kolaylığı ve güvenlik arasında denge kurmasına olanak tanır. Farklı eşiklerde birden fazla zaman kilidi süresi ayarlamak gibi daha karmaşık bir koruyucu mimari, yasal hesapların kurtarılma başarısını maksimize ederken, hırsızlık riskini en aza indirmeye yardımcı olur.
Vasi seçimi için birkaç seçenek vardır:
ZK ile paketlenmiş merkezi ID, yeni kullanıcılar için daha dostça. Cüzdan, kullanıcıların doğrudan e-posta adresini vasisi olarak belirlemesine izin veren basit bir entegrasyon UI'sı sunmalıdır ve buna bağlı olarak ilgili zk-email Ethereum adresini otomatik olarak oluşturmalıdır. İleri düzey kullanıcılar, oluşturulan adresin doğruluğunu doğrulayabilmelidir.
Yeni kullanıcılar için, cüzdan basit seçenekler sunabilir, örneğin zk-email tabanlı, yerel depolama anahtarı ve sağlayıcı yedek anahtarı içeren 2-of-3 çözümü. Kullanıcı deneyimi arttıkça veya varlıklar çoğaldıkça, daha fazla gözetmen eklemeleri önerilmelidir.
Uygulama içi cüzdan entegrasyonu kaçınılmazdır, ancak kullanıcıların tüm cüzdanları bir araya getirip erişim kontrolünü merkezi bir şekilde yönetebilmesi gerekir. Basit bir yöntem, kullanıcıların ana cüzdanı, tüm uygulama içi cüzdanların koruyucusu olarak ayarlamalarına izin veren hiyerarşik bir sistem kullanmaktır.
Kullanıcıları dolandırıcılıklardan ve diğer dış tehditlerden koruma
Hesap güvenliğinin yanı sıra, mevcut cüzdan sahte adresleri, kimlik avını, dolandırıcılığı vb. tanıma konusunda birçok çalışma yaptı. Ancak, birçok önlem hala oldukça ilkel; örneğin, yeni bir adrese token göndermeden önce, miktar ne olursa olsun, tıklayıp onaylama zorunluluğu. Bu, farklı tehdit kategorilerine yönelik sürekli iyileştirme gerektiriyor, kalıcı bir çözüm yok.
Gizlilik
Ethereum'un gizliliğine artık daha ciddi yaklaşma zamanı. ZK-SNARK teknolojisi oldukça gelişmiştir, arka kapıya bağlı olmayan gizlilik teknolojileri ( gibi gizlilik havuzları ) giderek olgunlaşmaktadır, ikincil altyapılar olan Waku ve ERC-4337 mempool'ları da kademeli olarak istikrara kavuşmaktadır. Ancak şu anda gizli transferler için kullanıcıların "gizlilik cüzdanı" indirmesi gerekmektedir, bu da zorluğu artırmakta ve kullanıcı sayısını azaltmaktadır. Çözüm, gizli transferleri doğrudan cüzdan içine entegre etmektir.
Basit bir uygulama, cüzdanın kullanıcının bazı varlıklarını "gizli bakiye" olarak gizlilik havuzunda saklamasıdır. Para transferi sırasında gizlilik havuzundan otomatik olarak çıkılır, fon alındığında otomatik olarak görünmez adres oluşturulur.
Ayrıca, cüzdan kullanıcıların katıldığı her uygulama için otomatik olarak yeni adresler oluşturabilir. Mevduatlar gizlilik havuzundan gelir, çekimler doğrudan gizlilik havuzuna gider. Bu, kullanıcıların farklı uygulamalardaki etkinliklerini birbirinden ayırmalarına olanak tanır.
Bu, yalnızca varlık transferi gizliliğini korumanın doğal bir yolu değil, aynı zamanda kimlik gizliliğini korumanın bir yoludur. Zincir üzerindeki kimlikler zaten mevcuttur, örneğin kimlik doğrulama uygulamaları, token tabanlı sohbetler vb. Bu ekosistemin de gizliliği korumasını istiyoruz, yani kullanıcıların zincir üzerindeki faaliyetleri tek bir yerde toplanmamalıdır: her proje ayrı ayrı saklanmalı, yalnızca kullanıcı cüzdanı tüm kanıtları aynı anda görebilmelidir. Her kullanıcı için çoklu hesapları destekleyen bir ekosistem bu hedefe ulaşılmasına yardımcı olur, zincir dışı kanıt protokolleri olan EAS ve Zupass da aynı şekilde.
Bu, Ethereum'un gizliliği için orta vadeli pragmatik bir vizyonu temsil ediyor. L1 ve L2'de gizlilik koruma transferlerini daha verimli ve güvenilir hale getirecek bazı işlevlerin eklenmesi mümkün olsa da, şu anda uygulanabilir. Bazı gizlilik savunucuları, yalnızca tamamen gizliliğin kabul edilebilir olduğunu düşünüyor, örneğin tüm EVM'yi şifrelemek gibi. Bu, ideal bir uzun vadeli sonuç olabilir, ancak programlama modelinde daha temel bir yeniden düşünmeyi gerektirir ve şu anda dağıtılabilir olgunluğa ulaşmamıştır. Yeterince büyük bir anonim grup elde etmek için varsayılan gizliliğe gerçekten ihtiyacımız var. Ancak, öncelikle (1) hesaplar arası transferlere, (2) kimlik ve ilgili kullanım durumlarına (, örneğin özel kanıt ) gibi, pragmatik ilk adım olarak odaklanmak daha kolaydır ve cüzdanlar hemen kullanılmaya başlanabilir.
Ethereum cüzdanı da veri cüzdanı olmalıdır
Herhangi bir geçerli gizlilik çözümü, kullanıcıların verilerini ödemeler, kimlik veya diğer kullanım durumları için çevrimdışı depolama gereksinimi doğurur. Modern gizlilik protokolleri bazen zincir üzerinde şifreli verileri saklar, tek bir özel anahtar ile şifre çözme kullanır. Bu risklidir, çünkü anahtar sızdırılırsa veya kuantum bilgisayarlar çalışır hale gelirse, tüm veriler açığa çıkar. Zincir dışı kanıtlar, zincir dışı veri depolama gereksinimini daha belirgin hale getirir.
Cüzdan sadece zincir üzerindeki erişim izinlerini depolamakla kalmaz, aynı zamanda kullanıcı özel verilerini de depolaması gerekir. Kripto olmayan dünya da bunu giderek daha fazla anlamaya başlıyor. Verilerin erişilebilirliği ve sızdırılmaya karşı korunması etrafında sağlam garantiler inşa etmemiz gerekiyor. Bu çözümleri üst üste koymak mümkün olabilir: Eğer N tane vekil varsa, bu N vekil arasında M-of-N gizli paylaşım kullanarak verileri depolayın. Veriler esasen koruması daha zor, çünkü birinin veri payını geri almak mümkün değil, ancak mümkün olduğunca güvenli merkeziyetsiz barındırma çözümleri önermeliyiz.
Güvenli Zincir Erişimi
Şu anda cüzdan, zincir bilgilerini almak için RPC sağlayıcısına bağımlıdır, bu iki açığın varlığını taşır:
İdeal olarak, bu iki açığı kapatmayı umuyoruz. İlk sorunun çözümü, L1 ve L2 için standart hafif istemciler gerektirir ve doğrudan blok zinciri konsensüsünü doğrular. Helios, L1 için bunu gerçekleştirmiştir ve bazı L2'leri desteklemeye başlamıştır. Tüm L2'leri kapsamak için, L2'yi temsil eden yapılandırma sözleşmesi aracılığıyla en son durum kökünü almak ve durum ve makbuz kanıtlarının mantığını doğrulamak için bir standart gereklidir. Bu şekilde, cüzdanın L1 ve L2 üzerindeki herhangi bir durum veya olayı güvenli bir şekilde doğrulamasını sağlayan evrensel bir hafif istemciye sahip olabiliriz.
Gizlilik için, şu anda tek gerçek yöntem kendi tam düğümünüzü çalıştırmaktır. Ancak L2'nin yaygınlaşmasıyla, her şeyi çalıştıran tam düğüm işletmek giderek daha zor hale geliyor. Buradaki hafif istemci eşdeğeri özel bilgi alma )PIR(. PIR, tüm veri kopyalarını saklayan sunucuları ve sunucuya şifreli talepler gönderen istemcileri içerir. Sunucu tüm veriler üzerinde hesaplamalar yapar, istemcinin ihtiyaç duyduğu şifreli verileri geri dönerken, istemcinin hangi verilere eriştiğini bilmez.
Sunucunun dürüstlüğünü sağlamak için, her bir veritabanı öğesi Merkle dalı olarak tasarlanmıştır, istemci hafif istemci ile doğrulama yapabilir.
PIR hesaplama miktarı çok büyük. Çözümler arasında şunlar bulunmaktadır:
Ethereum ortamında gizliliği maksimize ederken pratikliği korumak için doğru teknik kombinasyonunu bulmak açık bir araştırma sorusudur.
![Vitalik yeni makale: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseltme])https://img-cdn.gateio.im/webp-social/moments-ab5913a80a4549d9fec805c19442956b.webp(
İdeal Anahtar Kasası Cüzdanı
cross-chain L2 bağlamında, başka bir sorunsuz çalışması gereken önemli süreç hesap doğrulamasını değiştirmektir.