İdeal Ethereum Cüzdanı Vizyonu: cross-chain deneyiminden gizlilik korumasına kadar kapsamlı bir yükselme

Ethereum temel altyapı yığını içindeki Cüzdan katmanı son derece önemlidir, ancak genellikle çekirdek L1 araştırmacıları ve geliştiricileri tarafından hafife alınır. Cüzdan, kullanıcıların Ethereum dünyasıyla etkileşimde bulunduğu penceredir; kullanıcıların Ethereum ve onun uygulamalarının sunduğu merkeziyetsizlik, sansüre dayanıklılık, güvenlik, gizlilik gibi özelliklerden yararlanabilmesi, Cüzdan'ın bu özelliklere sahip olup olmamasına bağlıdır.

Son zamanlarda Ethereum cüzdanları, kullanıcı deneyimi, güvenlik ve işlevsellik açısından önemli ilerlemeler kaydetti. Bu makale, ideal bir Ethereum cüzdanının sahip olması gereken özelliklere dair bazı görüşlerimi paylaşmayı amaçlıyor. Bu, tamamlayıcı bir liste değil, kripto punk eğilimlerimi yansıtıyor, güvenlik ve gizliliğe odaklanıyor, kullanıcı deneyimi açısından bazı eksiklikler olabilir. Kullanıcı deneyimini optimize etme konusunda, yalnızca dağıtım yapmak ve geri bildirimlere göre iterasyon yapmak, bir istek listesinden daha etkili olduğunu düşünüyorum; bu nedenle güvenlik ve gizlilik özelliklerine odaklanmanın en değerli olduğunu hissediyorum.

cross-chain L2 işlemlerinin kullanıcı deneyimi

Artık L2 kullanıcı deneyimini iyileştirmek için giderek daha ayrıntılı bir yol haritası var, kısa ve uzun vadeli bölümleri içeriyor. Burada kısa vadeli bölüm üzerinde durulmaktadır: Bugün teorik olarak hala uygulanabilir olan fikirler.

Kilit fikir şudur: (1) yerleşik cross-chain L2 gönderim işlevi, (2) zincir özel adresleri ve ödeme talepleri. Cüzdanınız, ilgili ERC taslağı tarzına uyan bir zincir özel adresi sağlamalıdır.

Birisi ( veya bir uygulama ) size bu formatta bir adres sağladığında, bunu cüzdanınızdaki "Alıcı" alanına yapıştırabilmeli ve ardından "Gönder"e tıklamalısınız. Cüzdan, gönderim verilerini mümkün olan her şekilde otomatik olarak işlemelidir:

• Eğer hedef zincir üzerinde yeterli türde token'e sahipseniz, doğrudan gönderin.
• Eğer diğer zincirlerde gerekli türde tokenleriniz varsa, ERC-7683 gibi protokolleri kullanarak ( aslında cross-chain DEX ) gönderin.
• Eğer aynı zincir veya diğer zincirlerde farklı türlerde token'larınız varsa, DEX kullanarak bunları doğru zincirde doğru türde paraya dönüştürün ve gönderin. Bu, kullanıcının açık iznini gerektirir: kullanıcı ödenecek ücreti ve alıcının alacağı miktarı görecektir.

Yukarıda belirtilen durum, "kopyala-yapıştır adresi ( veya ENS, örneğin vitalik.eth@optimism.eth) birisi size ödeme yaparsa" için geçerlidir. Dapp'ın depozit talep ettiği durumlar için, ideal süreç web3 API'sinin genişletilmesi ve dapp'ın zincir spesifik ödeme talepleri göndermesine izin verilmesidir. Cüzdanınız, bu talebi herhangi bir şekilde karşılayabilecektir. İyi bir kullanıcı deneyimi sağlamak için, getAvailableBalance talebinin de standartlaştırılması gerekmekte ve cüzdan, kullanıcı varlıklarını hangi zincirlerde varsayılan olarak saklayacağına dikkatlice karar vermelidir, böylece güvenliği ve transfer kolaylığını maksimuma çıkarabilir.

Zincir belirli ödeme talepleri ayrıca mobil cüzdanın taraması için QR koduna yerleştirilebilir. Yüz yüze ( veya çevrimiçi ) tüketici ödeme senaryolarında, alıcı QR kodu veya web3 API çağrısı yapacaktır ve "Ben zincir X üzerinde Y birim Z tokeni istiyorum, referans ID veya geri çağırma W" ifadesini belirtecektir, cüzdan bu talebi karşılamak için istediği yöntemi seçebilir. Diğer bir seçenek ise talep bağlantısı protokolüdür; kullanıcı cüzdanı, belirli bir miktar fonu zincir üzerindeki sözleşmelerinden almak için talep yetkisini içeren bir QR kodu veya URL oluşturur, alıcının fonları kendi cüzdanına nasıl aktaracağını anlaması gerekecektir.

Bir diğer ilgili konu, gaz ödemeleridir. Eğer ETH bulunmayan bir L2 üzerinde varlık alırsanız, o L2'de işlem göndermek için cüzdan, ( gibi protokolü otomatik olarak kullanabilmelidir, bu da ETH bulunan zincirden gaz ödemesi yapar. Eğer cüzdan, gelecekte L2 üzerinde daha fazla işlem yapacağınızı öngörüyorsa, sadece DEX üzerinden yüzlerce gaz değerinde ETH göndermelidir, böylece gelecekteki işlemler orada doğrudan gaz ödemesi yapabilir, çünkü daha ucuzdur ).

Hesap Güvenliği

Hesap güvenliği zorluklarının bir kavramsal yolu, mükemmel bir cüzdanın iki alanda da işlev görmesi gerektiğidir: (1) kullanıcıyı cüzdan geliştiricilerinin hacker saldırılarından veya kötü niyetli eylemlerinden korumak, (2) kullanıcıyı kendi hatalarının etkilerinden korumak.

Benim tercih ettiğim çözüm, sosyal kurtarma ve çoklu imza cüzdanıdır, katmanlı erişim kontrolü ile. Kullanıcı hesaplarında iki katmanlı anahtar bulunmaktadır: anahtar ve N adet ( koruyucu, burada N=5). Anahtar, düşük değerli ve finansal olmayan işlemleri gerçekleştirebilir. Çoğu koruyucu, yüksek değerli işlemleri gerçekleştirmek için gereklidir: (1), örneğin hesapta bulunan tüm değeri göndermek, (2) anahtarını değiştirmek veya herhangi bir koruyucuyu değiştirmek gibi. Gerekirse, anahtarın yüksek değerli işlemleri zaman kilidi aracılığıyla gerçekleştirmesine izin verilebilir.

Bu temel tasarım, genişletilebilir. Oturum anahtarları ve ERC-7715 gibi izin mekanizmaları, farklı uygulamalar arasındaki kolaylık ve güvenlik arasında bir denge sağlamaya yardımcı olabilir. Farklı eşiklerde birden fazla zaman kilidi süresine sahip daha karmaşık gözlemci mimarisi, yasal hesapların başarıyla geri kazanılma fırsatlarını en üst düzeye çıkarmaya ve hırsızlık riskini en aza indirmeye yardımcı olabilir.

Vasi Seçimi

Tecrübeli kripto kullanıcılar için, uygulanabilir bir seçenek arkadaşların ve ailelerin anahtarlarıdır. Herkesten yeni bir adres talep edilmesi durumunda, kim olduklarını kimse bilmek zorunda değildir - aslında, bekçiler birbirlerinin kimliğini bilmek zorunda bile değildir. Eğer mesajlaşmıyorlarsa, anlaşma yapma olasılığı oldukça düşüktür. Ancak, çoğu yeni kullanıcı için bu seçenek mevcut değildir.

İkinci seçenek kurumsal gözetmenlerdir: yalnızca talebiniz üzerine başka onay bilgileri aldıklarında işlemi imzalayan hizmetler sunan şirketler, örneğin onay kodu veya yüksek değerli kullanıcılar için video görüşmesi. Uzun zamandır bunları oluşturma çabaları devam ediyor, 2013'te CryptoCorp'a yaptığım tanıtım gibi. Ancak, bugüne kadar bu şirketler büyük bir başarı elde edemediler.

Üçüncü seçenek, cep telefonları, masaüstü bilgisayarlar, donanım cüzdanları gibi birden fazla kişisel cihaz ( kullanmaktır. Bu mümkündür, ancak tecrübesiz kullanıcılar için ayarlamak ve yönetmek zordur. Ayrıca, aynı yerde bulunduklarında cihazların aynı anda kaybolma veya çalınma riski de vardır.

Son zamanlarda, daha fazla genel anahtar tabanlı çözüm görmeye başladık. Anahtarlar yalnızca cihazınızda yedeklenebilir, bu da onu kişisel cihaz çözümü haline getirir, ayrıca bulutta yedeklenebilir, bu da güvenliğin karmaşık karma şifreleme güvenliğine, kuruluşlara ve güvenilir donanım varsayımlarına bağlı olmasını sağlar. Aslında, genel anahtarlar ortalama kullanıcılar için değerli bir güvenlik artışı sağlar, ancak yalnızca bunlara dayanmak, kullanıcıların bir ömür boyu biriktirdiği tasarruflarını korumak için yeterli değildir.

Şans eseri, ZK-SNARK ile dördüncü bir seçeneğimiz var: ZK paketli merkezi ID. Bu türler arasında zk-email, Anon Aadhaar, Myna Cüzdan gibi seçenekler bulunmaktadır. Temelde, merkezi ID'yi çeşitli formlarda ) şirketi veya devlet ( olarak alabilir ve bunu Ethereum adresine dönüştürebilirsiniz. İşlemi gönderebilmek için yalnızca merkezi ID'ye sahip olduğunuzu kanıtlayan ZK-SNARK oluşturmanız gerekmektedir.

Bu ek ile artık geniş bir seçeneğe sahibiz, ZK paketli merkezi ID, benzersiz bir "yeni başlayan dostluğu" sunuyor.

Bunun için, basit ve entegre bir UI aracılığıyla gerçekleştirilmesi gerekmektedir: Sadece "example@gmail.com" adresini vasisi olarak belirtmeniz yeterlidir, bu otomatik olarak ilgili zk-email Ethereum adresini oluşturmalıdır. İleri düzey kullanıcılar, e-posta ) ve muhtemel saklanan gizlilik tuz değerini ( açık kaynaklı üçüncü taraf uygulamalara girmeli ve oluşturulan adresin doğru olduğunu onaylamalıdır. Diğer desteklenen vasisi türleri için de aynı şekilde olmalıdır.

Dikkat edilmesi gereken bir nokta, mevcut zk-email'in karşılaştığı pratik bir zorluğun, her birkaç ayda bir değiştirilen anahtarlara dayanan DKIM imzasına güvenmesidir; bu anahtarlar kendileri başka bir kuruluş tarafından imzalanmamıştır. Bu, mevcut zk-email'in sağlayıcının kendisinden öte bir tür güven gereksinimi taşıdığı anlamına gelir; eğer zk-email, güvenilir donanım içinde güncellenmiş anahtarları TLSNotary ile doğruluyorsa, bu durumu azaltabilir ama ideal değildir. Umarım e-posta sağlayıcıları, DKIM anahtarlarını doğrudan imzalamaya başlayabilir. Şu anda, bir zk-email gözetmeni kullanmayı öneriyorum, ancak çoğu gözetmenin kullanılmasını önermiyorum: zk-email'in bozulması durumunda fonları kullanılamaz duruma getiren bir yapı içinde fon depolamayın.

![Vitalik'in yeni makalesi: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumasına kadar kapsamlı bir yükseliş])https://img-cdn.gateio.im/webp-social/moments-6e92b6b051653e68d5f93ed0d91891eb.webp(

Yeni Kullanıcılar ve Uygulama İçi Cüzdan

Yeni kullanıcılar aslında ilk kayıt sırasında çok sayıda gözlemci girmeyi istemiyor. Bu nedenle, cüzdan onlara çok basit bir seçenek sunmalıdır. Doğal bir yol, e-posta adreslerinde zk-email kullanmak, kullanıcı cihazında yerel olarak saklanan anahtar )'in genel anahtar ( ile birlikte sağlayıcı tarafından tutulan yedek anahtar ile 2-of-3 seçeneği sunmaktır. Kullanıcı daha deneyimli hale geldikçe veya daha fazla varlık biriktirdikçe, bir noktada onlara daha fazla gözlemci eklemeleri için bir uyarı yapılmalıdır.

Cüzdanın uygulamaya entegrasyonu kaçınılmazdır, çünkü kripto para kullanıcılarını çekmeye çalışan uygulamalar, kullanıcıların aynı anda iki yeni uygulama indirmesini istemez. ) uygulamanın kendisi, artı Ethereum cüzdanı ( karmaşık bir kullanıcı deneyimi yaratır. Ancak, birçok uygulama içi cüzdan kullanıcısının tüm cüzdanlarını bir araya getirebilmesi gerekir, böylece yalnızca bir "erişim kontrol sorunu" ile ilgilenmek zorunda kalır. En basit yol, hızlı bir "bağlantı" sürecine sahip hiyerarşik bir yaklaşım benimsemektir; bu, kullanıcının ana cüzdanını tüm uygulama içi cüzdanların koruyucusu olarak ayarlamasına izin verir. Farcaster istemcisi Warpcast bunu desteklemektedir.

![Vitalik yeni makale: İdeal cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumasına kadar kapsamlı bir yükseltme])https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(

Kullanıcıları dolandırıcılıktan ve diğer dış tehditlerden koruma

Hesap güvenliğinin yanı sıra, günümüzde cüzdanlar sahte adresleri, kimlik avını, dolandırıcılığı ve diğer dış tehditleri tanımak için birçok işlevsellik geliştirmiştir ve kullanıcıları korumak için çaba sarf etmektedir. Aynı zamanda, birçok önlem hala oldukça ilkel: yeni bir adrese ETH veya diğer token'ları göndermek için tıklama gerektirmesi gibi, gönderilen miktar 100 dolar veya 100,000 dolar olsun fark etmeksizin. Burada tek bir panzehir yoktur. Farklı tehdit kategorilerine yönelik bir dizi yavaş ama sürekli düzeltme ve iyileştirme söz konusudur. Ancak, iyileştirmeye yönelik çabaların devam etmesi oldukça değerlidir.

![Vitalik yeni makale: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumasına kadar kapsamlı bir yükseltme])https://img-cdn.gateio.im/webp-social/moments-9852b894445658cf6d25e8e105ea1445.webp(

Gizlilik

Artık Ethereum gizliliğini daha ciddiye alma zamanı. ZK-SNARK teknolojisi oldukça ileri düzeyde ve düzenleyici riskleri azaltmak için arka kapılara dayanmadığı gibi, gizlilik teknolojileri ), gizlilik havuzları ( giderek olgunlaşıyor, Waku ve ERC-4337 mempool'ları gibi ikincil altyapılar da yavaş yavaş stabil hale geliyor. Ancak, şu anda Ethereum üzerinde özel transfer yapmak için kullanıcıların "gizlilik cüzdanı" indirmesi ve kullanması gerekiyor, bunlar arasında Railway ) veya gizli adresler için Umbra ( bulunuyor. Bu, büyük ölçüde rahatsızlığı artırmakta ve özel transfer yapmak isteyenlerin sayısını azaltmaktadır. Çözüm, özel transferleri doğrudan cüzdanlara entegre etmektir.

Basit bir uygulama aşağıdaki gibidir. Cüzdan, kullanıcı varlıklarının bir kısmını "özel bakiye" olarak gizlilik havuzunda saklayabilir. Kullanıcı para transferi yaparken, önce gizlilik havuzundan otomatik olarak çıkılır. Kullanıcı fon almak istediğinde, cüzdan otomatik olarak görünmez bir adres oluşturabilir.

Ayrıca, Cüzdan kullanıcıların katıldığı her uygulama için otomatik olarak yeni adresler ) oluşturabilir, örneğin defi protokolü (. Mevduatlar gizlilik havuzundan gelir, çekimler doğrudan gizlilik havuzuna gider. Bu, kullanıcıların herhangi bir uygulamadaki aktivitelerini diğer uygulamalardaki aktivitelerden ayırmalarına olanak tanır.

Bu teknoloji yalnızca gizli varlıkların transferini korumanın doğal bir yolu değil, aynı zamanda gizli kimlikleri korumanın doğal bir yoludur. Kimlik zincir üzerinde gerçekleşmiştir: Kimlik kanıtı ile kontrol edilen herhangi bir uygulama ), Gitcoin Grants (, herhangi bir token ile kontrol edilen sohbet, Ethereum uyumlu protokoller vb., hepsi zincir üstü kimliktir. Bu ekosistemin gizliliği korumasını da umuyoruz. Bu, kullanıcıların zincir üstü faaliyetlerinin tek bir yerde toplanmaması gerektiği anlamına gelir: Her proje ayrı olarak saklanmalı, kullanıcı cüzdanı "küresel görünüm"e sahip olan tek şey olmalıdır.