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

Ethereum altyapısındaki cüzdan katmanı çok önemlidir, ancak genellikle çekirdek L1 araştırmacıları ve geliştiricileri tarafından yeterince takdir edilmez. Cüzdan, kullanıcıların Ethereum dünyasıyla etkileşime girdiği penceredir; yalnızca cüzdan kendisi gerekli özelliklere sahip olduğunda, kullanıcılar Ethereum ve onun uygulamalarının sunduğu merkeziyetsizlik, sansüre karşı dayanıklılık, güvenlik ve gizlilik gibi özelliklerden gerçekten faydalanabilir.

Son zamanlarda Ethereum cüzdanları, kullanıcı deneyimi, güvenlik ve işlevsellik konusunda önemli ilerlemeler kaydetti. Bu makale, ideal bir Ethereum cüzdanının sahip olması gereken bazı özellikleri açıklamayı amaçlamaktadır. Bu, eksiksiz bir liste değildir; yazarın kripto punk eğilimlerini yansıtır ve güvenlik ile gizliliğe odaklanır, kullanıcı deneyimi açısından bazı eksiklikler olabilir. Ancak, geribildirimlere dayanarak basit bir şekilde dağıtım ve yineleme yapmak yerine, istek listesi kullanıcı deneyimini optimize etmede daha az etkili olabilir; bu nedenle güvenlik ve gizlilik özelliklerine odaklanmak daha değerli olabilir.

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

L2 kullanıcı deneyimini geliştirme yol haritası giderek daha net hale geliyor, kısa vadeli ve uzun vadeli kısımları içeriyor. Bu makalede kısa vadede uygulanabilir fikirler ele alınacaktır.

Temel düşünce: (, ) içinde L2 gönderim işlevselliği, ( zincirine özgü adresler ve ödeme talepleri ile birlikte. Cüzdan, kullanıcılara belirli bir ERC taslak stiline uygun bir adres sağlamalıdır.

Kullanıcı bu formatta bir adres aldığında, bunu cüzdanın "alıcı" alanına yapıştırabilir ve "gönder" butonuna tıklayabilir. Cüzdan, gönderim sürecini otomatik olarak işlemelidir:

• Hedef zincirde yeterli gerekli token varsa, doğrudan gönderin
• Eğer diğer zincirlerde gerekli tokenler varsa, ERC-7683 gibi bir cross-chain DEX protokolü kullanarak gönderin.
• Eğer aynı zincir veya diğer zincirlerde farklı türde tokenler varsa, DEX kullanarak doğru türdeki tokenlere dönüştürmek ve göndermek için kullanıcının açık izni gereklidir.

Bu, "kopyala-yapıştır adresi ile ödeme" senaryoları için geçerlidir. Dapp'ın depozito talep ettiği durumlarda, ideal uygulama web3 API'sini genişletmek ve dapp'ın zincir spesifik ödeme talepleri göndermesine izin vermektir. Cüzdan, bu talebi esnek bir şekilde karşılayabilir. İyi bir kullanıcı deneyimi sağlamak için getAvailableBalance talebinin standartlaştırılması gerekmektedir; cüzdan, kullanıcı varlıklarının hangi zincirlerde varsayılan olarak saklanacağını dikkatlice düşünmeli ve güvenlik ile transfer kolaylığı arasında bir denge sağlamalıdır.

Zincir belirli ödeme talepleri, mobil cüzdanların taraması için QR koduna da yerleştirilebilir. Yüz yüze veya çevrimiçi tüketim ödeme senaryolarında, alıcı "Zincir X üzerinde Y birimi token Z'ye ihtiyacım var, referans ID W" ifadesini gösteren bir QR kodu veya web3 API çağrısı yapabilir, cüzdan bu talebi esneklikle karşılayabilir. Diğer bir seçenek ise claim bağlantı protokolüdür, kullanıcı cüzdanı, talep yetkisini içeren bir QR kodu veya URL oluşturur, alıcı fonları kendi cüzdanına transfer etmekten sorumludur.

Diğer bir ilgili konu, gas ödemeleridir. Eğer kullanıcı, ETH olmayan bir L2 üzerinde varlık alıyorsa ve işlem göndermesi gerekiyorsa, cüzdanın otomatik olarak ) gibi protokoller kullanarak ETH bulunan diğer zincirlerden gas ödemesi yapabilmesi gerekir. Eğer cüzdan, kullanıcının gelecekte bu L2 üzerinde daha fazla işlem yapacağını öngörüyorsa, DEX üzerinden yüzlerce gas ödemesini karşılayacak kadar ETH gönderilmesi de mümkündür, böylece gelecekteki işlemler doğrudan L2 üzerinde daha ucuz bir şekilde gas ücreti ödeyebilir (.

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

Hesap Güvenliği

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

Önerilen çözüm, hiyerarşik erişim kontrolüne sahip sosyal kurtarma ve çoklu imza cüzdanıdır. Kullanıcı hesapları iki anahtar katmanına sahiptir: anahtar ve N tane gözetmen ), burada N=5(. Anahtar, düşük değerli ve finansal olmayan işlemler için kullanılabilir. Yüksek değerli işlemleri gerçekleştirmek için çoğu gözetmenin katılması gereklidir: )1(, örneğin, hesapta bulunan tüm fonları göndermek, )2( anahtarı değiştirmek veya herhangi bir gözetmeni 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 anahtarı ve ERC-7715 gibi yetki mekanizmaları, farklı uygulamalar arasında kullanım kolaylığı ve güvenlik dengesini sağlamaya yardımcı olabilir. Farklı eşiklerde birden fazla zaman kilidi olan daha karmaşık bir bekçi mimarisi, yasal hesapların başarıyla geri kazanılma olasılığını maksimize ederken, hırsızlık riskini en aza indirebilir.

![Vitalik yeni makale: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseliş])https://img-cdn.gateio.im/webp-social/moments-66ec52b10d00460414381b99c15622ee.webp(

) Vasıf Seçimi

Kripto topluluğunda deneyimli kullanıcılar, arkadaşlarının ve ailelerinin anahtarlarını veli olarak seçebilirler. Herkesten yeni bir adres sağlaması isteniyorsa, hatta birbirlerinin kimliğini bilmesine bile gerek yoktur. Ancak bu, çoğu yeni kullanıcı için geçerli değildir.

İkinci seçenek, kurumsal koruyucudur: yalnızca kullanıcı talebine göre ek doğrulama bilgilerini (, örneğin onay kodu veya yüksek değerli kullanıcıların video görüşmesi ) aldıklarında işlemleri imzalayan bir hizmet sunmaktadır. Uzun zamandır bu tür hizmetlerin kurulması için çaba gösterilmiştir, ancak şu anda çok başarılı değillerdir.

Üçüncü seçenek, cep telefonları, masaüstü bilgisayarlar, donanım cüzdanları gibi birden fazla kişisel cihaz ### kullanmaktır. Bu uygulanabilir, ancak yeni kullanıcılar için ayar ve yönetim açısından daha zordur. Aynı yerde bulunduklarında, cihazların aynı anda kaybolma veya çalınma riski de vardır.

Son zamanlarda, daha fazla evrensel anahtara dayalı çözümler görmeye başladık. Anahtarlar yalnızca cihazda yedeklenebilir ve kişisel bir cihaz çözümü haline gelebilir veya bulutta yedeklenebilir; güvenlik karmaşık hibrit şifreleme güvenliğine, kurumsal ve güvenilir donanım varsayımlarına dayanır. Normal kullanıcılar için değerli bir güvenlik artışı olsa da, bunlara dayanarak kullanıcıların bir ömür boyu biriktirdikleri tasarruflarını korumak yeterli değildir.

Neyse ki, ZK-SNARK ile artık dördüncü bir seçeneğimiz var: ZK paketli merkezi ID. Bu tür, zk-email, Anon Aadhaar, Myna Cüzdan gibi çeşitli formları içerir. Temelde, ( şirket veya hükümet )'ye ait merkezi ID'nin çeşitli biçimlerini alabilir ve bunları Ethereum adresine dönüştürebiliriz. Kullanıcılar, merkezi ID'ye sahip ZK-SNARK kanıtı oluşturarak işlemler gönderebilir.

ZK ile paketlenmiş merkeziyetsiz ID, benzersiz bir "yeni başlayan dostu" özelliğine sahiptir. Bunun için, kullanıcıların "example@gmail.com"u vasisi olarak belirtmesi yeterlidir; arka planda otomatik olarak ilgili zk-email Ethereum adresini oluşturmalıdır. İleri düzey kullanıcılar, e-posta ( ve muhtemel olarak kaydedilen gizlilik tuzunu ) açık kaynaklı üçüncü taraf uygulamaya girebilmeli ve oluşturulan adresin doğru olduğunu onaylayabilmelidir. Desteklenen diğer vasisi türleri için de aynı şey geçerli olmalıdır.

Dikkat edilmesi gereken bir nokta, mevcut zk-email'in karşılaştığı gerçek bir zorluk olan DKIM imzasına dayanmasıdır; bu imza, her birkaç ayda bir değiştirilen anahtarları kullanır ve bu anahtarlar kendileri başka bir kurum tarafından imzalanmamıştır. Bu, günümüzdeki zk-email'in bir dereceye kadar sağlayıcıya güvenmesi gerektiği anlamına gelir; eğer zk-email, güncellenmiş anahtarları doğrulamak için güvenilir donanım içinde TLSNotary kullanırsa, bu durumu azaltabilir, ancak bu ideal değildir. E-posta sağlayıcılarının DKIM anahtarlarını doğrudan imzalamaya başlamasını umuyoruz. Şu anda, bir zk-email'in gözetmen olarak kullanılmasını öneriyoruz, ancak çoğu gözetmenin bu şekilde kullanılmasını önermiyoruz: zk-email'in bozulması, fonların kullanılamaz hale gelmesi anlamına gelir.

( Yeni kullanıcılar ve uygulama içi Cüzdan

Yeni kullanıcılar aslında ilk kayıttan itibaren çok sayıda koruyucu girmeyi istemiyorlar. 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 depolanan anahtar )'in evrensel anahtar olması ve sağlayıcı tarafından tutulan yedek anahtar ile 2-of-3 seçeneği sunmaktır. Kullanıcı daha fazla deneyim veya varlık biriktirdikçe, bir noktada onlara daha fazla koruyucu eklemeleri gerektiği hatırlatılmalıdır.

Cüzdanın uygulamaya entegrasyonu kaçınılmazdır, çünkü kripto olmayan kullanıcıları çekmeye çalışan uygulamalar, kullanıcıların aynı anda iki yeni uygulama indirmesini istemez. ( uygulamanın kendisi ve 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ı bir araya bağlayabilmesi gerekir, böylece sadece bir "erişim kontrol sorunu" ile ilgilenmeleri yeterli olur. En basit yöntem, hızlı bir "bağlantı" süreci aracılığıyla ana cüzdanın tüm uygulama içi cüzdanların koruyucusu olarak ayarlanmasına olanak tanıyan hiyerarşik bir plan benimsemektir.

![Vitalik'in yeni makalesi: İdeal Cüzdanın vizyonu, cross-chain deneyiminden gizlilik korumaya kadar kapsamlı bir yükseltme]###https://img-cdn.gateio.im/webp-social/moments-2439f49163d0212333ea4207f34cdbef.webp(

) Kullanıcıları dolandırıcılık ve diğer dış tehditlerden korumak

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 çalışma yapmaktadır ve kullanıcıları korumak için çaba göstermektedir. Aynı zamanda, birçok önlem hala oldukça ilkel: örneğin, gönderim miktarı ne olursa olsun, ETH veya diğer token'ları herhangi bir yeni adrese göndermek için tıklama gerekmektedir. Burada tek bir mucize çözüm yoktur; daha ziyade, farklı tehdit kategorilerine yönelik sürekli iyileştirmelerin bir dizi vardır. Bu alanda iyileştirme çabalarına devam etmek çok değerlidir.

Gizlilik

Artık Ethereum'un gizliliğini daha ciddiye alma zamanı geldi. ZK-SNARK teknolojisi oldukça gelişti, arka kapılara dayanarak düzenleyici riskleri azaltan gizlilik teknolojileri (, gizlilik havuzları ) giderek olgunlaşıyor, Waku ve ERC-4337 mempool'ları gibi ikincil altyapılar da yavaş yavaş daha istikrarlı hale geliyor. Ancak, şu anda Ethereum üzerinde özel transferler yapmak isteyen kullanıcıların "gizlilik cüzdanı"nı açıkça indirip kullanmaları gerekiyor. Bu büyük bir rahatsızlık yaratıyor ve özel transfer yapmaya istekli olanların sayısını azaltıyor. Çözüm, özel transferleri cüzdanlara doğrudan 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 depolayabilir. Kullanıcı transfer gerçekleştirdiğinde, önce otomatik olarak gizlilik havuzundan çıkacaktır. Kullanıcı fon alması gerektiğ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 ### gibi defi protokolleri ( için otomatik olarak yeni bir adres oluşturabilir. Mevduatlar gizlilik havuzundan gelecektir, çekimler doğrudan gizlilik havuzuna girecektir. Bu, kullanıcıların herhangi bir uygulamadaki etkinliklerinin diğer uygulamalardaki etkinliklerle bağlantısının kesilmesini sağlar.

Bu teknoloji, yalnızca gizli varlık transferini korumanın doğal bir yolu değil, aynı zamanda gizli kimlikleri korumanın da doğal bir yoludur. Kimlik, zincir üzerinde gerçekleşti: Kimlik doğrulama kontrollü uygulamalar ) gibi Gitcoin Grants (, herhangi bir token kontrollü sohbet, Ethereum'a uygun protokoller vb. hepsi zincir üzerindeki kimliklerdir. Bu ekosistemin gizliliği korumasını umuyoruz. Bu, kullanıcıların zincir üzerindeki etkinliklerinin tek bir yerde toplanmaması gerektiği anlamına gelir: her proje ayrı ayrı saklanmalı, kullanıcıların cüzdanları "küresel görünüm"e sahip olan tek şey olmalı ve tüm kanıtları aynı anda görebilmelidir. Her kullanıcının birden fazla hesaba sahip olduğu yerel ekosistem, bu hedefe ulaşmaya yardımcı olur, EAS ve Zupass gibi zincir dışı kanıt protokolleri de öyledir.

Bu, orta vadede Ethereum'un gizliliği için pragmatik bir vizyonu temsil ediyor. L1 ve L2'de gizlilik koruma iletimini daha verimli ve güvenilir hale getirmek için bazı işlevlerin getirilmesi mümkün olmasına rağmen, şu anda bunu gerçekleştirmek mümkün. Bazı gizlilik savunucuları, kabul edilebilir tek şeyin her şeyin tam gizliliği olduğunu düşünüyor: tüm EVM'nin şifrelenmesi. Bu, ideal uzun vadeli bir sonuç olabilir, ancak programlama modelinde daha köklü bir yeniden düşünmeyi gerektiriyor.