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

Ethereum altyapı yığınındaki önemli katmanlardan biri Cüzdan'dır, ancak sıkça temel L1 araştırmacıları ve geliştiricileri tarafından hafife alınır. Cüzdan, kullanıcılar ile Ethereum dünyası arasında bir pencere işlevi görür; kullanıcılar yalnızca Ethereum ve onun uygulamaları tarafından sunulan herhangi bir merkeziyetsiz, sansüre dirençli, güvenli, gizlilik veya diğer özelliklerden yararlanabilirler, bunun şartı ise Cüzdan'ın da bu özelliklere sahip olmasıdır.

Son zamanlarda, Ethereum cüzdanları kullanıcı deneyimini, güvenliğini ve işlevselliğini geliştirme konusunda büyük ilerlemeler kaydetti. Bu makalenin amacı, ideal bir Ethereum cüzdanının sahip olması gereken bazı özelliklere dair görüşler sunmaktır. Bu, kapsamlı bir liste değildir; kriptografik punk eğilimlerini yansıtır, güvenlik ve gizliliğe odaklanır ve kullanıcı deneyimi açısından neredeyse kesinlikle eksiktir. Ancak, dilek listesi kullanıcı deneyimini optimize etme konusunda, geri bildirimlere dayanarak dağıtım ve yineleme yapmaktan daha etkili değildir; bu nedenle güvenlik ve gizlilik özelliklerine odaklanmak en değerli olandır.

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

Şimdi L2 kullanıcı deneyimini geliştirmeye yönelik giderek daha ayrıntılı bir yol haritası var, bu yol haritası kısa vadeli ve uzun vadeli bölümler içeriyor. Burada kısa vadeli bölümden bahsedeceğiz: bugün teorik olarak hala uygulanabilir olan fikirler.

Temel fikir, (i) yerleşik cross-chain L2 gönderimi ile (ii) zincir spesifik adres ve ödeme talepleridir. Cüzdan, kullanıcılara ilgili ERC taslağı stiline uyan bir adres sağlamalıdır.

Birisi ( veya bazı uygulamalar ) kullanıcıya bu formatta bir adres sağladığında, kullanıcı bunun cüzdanın "alıcı" alanına yapıştırabilmeli ve ardından "gönder" butonuna tıklamalıdır. Cüzdan, gönderilen verileri mümkün olan her şekilde otomatik olarak işlemelidir:

• Eğer kullanıcı hedef zincirde gerekli türde yeterli token'e sahipse, lütfen token'i doğrudan gönderin.
• Eğer kullanıcı başka bir zincirde gerekli türde bir token ( veya birden fazla diğer zincir ) varsa, ilgili protokolü ( kullanmak aslında bir cross-chain DEX ) ile token göndermektir.
• Eğer kullanıcı aynı zincirde veya diğer zincirlerde farklı türde tokenlere sahipse, bunları merkeziyetsiz borsa kullanarak doğru zincirde doğru türde paraya dönüştürmeli ve göndermelidir. Bu, kullanıcının açık iznini gerektirmelidir: kullanıcı ne kadar ücret ödediğini ve alıcının ne kadar ücret aldığını görecektir.

Yukarıdaki içerik, "Kullanıcı ( adresini veya ENS'yi kopyalayıp yapıştırır, örneğin, vitalik.eth @ optimism.eth)'e birisi kullanıcıya ödeme yapar" kullanım durumu için geçerlidir. Eğer dapp depozito talep ederse, ideal süreç web3 API'sini genişletmek ve dapp'in zincirle ilgili ödeme istekleri göndermesine izin vermektir. Daha sonra, cüzdan bu isteği gereken herhangi bir şekilde yerine getirebilecektir. Kullanıcı deneyimini iyileştirmek için getAvailableBalance isteğinin 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üvenlik ve transfer kolaylığı maksimize edilebilir.

Belirli bir zincire özgü ödeme talepleri QR koduna yerleştirilebilir, mobil cüzdan QR kodunu tarayabilir. Yüz yüze ( veya çevrimiçi ) tüketici ödeme senaryolarında, alıcı QR kodu veya web3 API çağrısı gönderir, "Zincir üzerinde X birim YZ token almak istiyorum, referans ID veya geri çağırma W ile" şeklinde bir mesaj gönderir, cüzdan bu talebi istediği şekilde karşılayabilir. Diğer bir seçenek, kullanıcının cüzdanının belirli bir miktar fon almak için talep yetkisi içeren bir QR kodu veya URL ürettiği claim bağlantı protokolüdür, alıcının yapması gereken, bu fonları kendi cüzdanına nasıl aktaracağını çözmektir.

Diğer ilgili konu gas ödemeleridir. Eğer kullanıcı ETH olmayan bir L2'de varlık alırsa ve o L2'de işlem göndermesi gerekiyorsa, cüzdan otomatik olarak protokolü kullanarak zincir üzerindeki Gas'ı ETH'nin bulunduğu yerden ödemelidir. Eğer cüzdan, kullanıcının gelecekte L2'de daha fazla işlem yapmasını istiyorsa, yalnızca DEX kullanarak, örneğin milyonlarca Gas değerinde ETH göndermelidir, böylece gelecekteki işlemler orada doğrudan Gas ( harcayabilir, çünkü bu daha ucuzdur ).

Hesap Güvenliği

Hesap güvenliği zorluklarının kavramsallaştırılmasının bir yolu, iyi bir cüzdanın aynı anda iki alanda işlev görmesi gerektiğidir: (i) kullanıcıları cüzdan geliştiricilerinin siber saldırılarından veya kötü niyetli saldırılarından korumak ve (ii) kullanıcıları kendi hatalarının etkilerinden korumak.

Buna en iyi çözüm, on yılı aşkın bir süredir sosyal kurtarma ve çoklu imza cüzdanlarıdır, katmanlı erişim kontrolü ile. Kullanıcı hesaplarının iki katmanlı anahtarı vardır: anahtar ve N tane gözetmen ( örneğin N = 5). Anahtar, düşük değerli ve finansal olmayan işlemleri gerçekleştirebilen bir anahtardır. Çoğu gözetmen, (i) yüksek değerli işlemleri gerçekleştirmek için gereklidir, örneğin hesapta bulunan tüm değeri göndermek veya (ii) anahtarı değiştirmek veya herhangi bir gözetmeni değiştirmek. Gerekirse, anahtarın zaman kilidi aracılığıyla yüksek değerli işlemleri gerçekleştirmesine izin verilebilir.

Yukarıda temel tasarım yer almakta, genişletilebilir. Oturum anahtarları ve ilgili yetki mekanizmaları, farklı uygulamaların kullanışlılığı ve güvenliği arasında farklı bir denge sağlamaya yardımcı olabilir. Farklı eşiklerde birden fazla zaman kilit süresine sahip daha karmaşık bir gözetim yapısı, yasal hesapların başarılı bir şekilde geri alınma şansını en üst düzeye çıkarırken, hırsızlık riskini minimize etmeye yardımcı olabilir.

Vasi kim veya ne olmalı?

Tecrübeli kripto para kullanıcıları topluluğundaki deneyimli kripto kullanıcıları için, kullanıcıların arkadaşları ve ailelerinin anahtarları iyi bir seçenek olabilir. Eğer kullanıcı herkesin kendisi için yeni bir adres sağlamasını isterse, o zaman kimse onların kim olduğunu bilmek zorunda değil – aslında, kullanıcının gözaltında bulunduğu kişilerin bile birbirlerinin kim olduğunu bilmesine gerek yok. Eğer kullanıcıya haber vermezlerse, bir araya gelme olasılıkları oldukça düşüktür. Ancak, çoğu yeni kullanıcı için bu seçenek mevcut değildir.

İkinci seçenek, yalnızca kullanıcıdan gelen talep üzerine diğer doğrulama bilgilerini aldığında işlemi imzalayan hizmetler sunan kurum gözetmenleridir: örneğin, onay kodu veya yüksek değerli kullanıcılar için video görüşmesi. İnsanlar uzun zamandır bunları yapmaya çalışıyor, örneğin 2013'te CryptoCorp tanıtıldı. Ancak, şu ana kadar bu şirketler pek başarılı olamadı.

Üçüncü seçenek, telefon, masaüstü bilgisayar, donanım cüzdanı ( gibi birden fazla kişisel cihazdır. Bu işe yarayabilir, ancak deneyimsiz kullanıcılar için ayarlamak ve yönetmek de oldukça zor olabilir. Aynı yerde bulunduklarında, cihazların aynı anda kaybolma veya çalınma riski de vardır.

Son zamanlarda, evrensel anahtarlara dayalı daha fazla şey görmeye başladık. Anahtar yalnızca kullanıcının cihazında yedeklenebilir, bu da onu kişisel bir cihaz çözümü haline getirir, ayrıca bulutta yedeklenebilir, bu da güvenliğini karmaşık karma şifre güvenliği, kurumlar ve güvenilir donanım varsayımlarına dayandırır. Gerçekten de, anahtarlar sıradan kullanıcılar için değerli bir güvenlik kazancı olmasına rağmen, yalnızca bunlara dayanmak, kullanıcıların hayat boyu birikimlerini korumak için yeterli değildir.

Şanslıyız ki, ZK-SNARK ile dördüncü bir seçeneğimiz daha var: ZK paketli merkezi ID. Bu tür, zk-email, Anon Aadhaar, Myna Cüzdanı vb. gibi seçenekleri içerir. Temelde, kullanıcılar çeşitli formlardaki ) şirket veya hükümet ( merkezi ID'lerini alabilir ve bunları Ethereum adresine dönüştürebilir, kullanıcılar yalnızca merkezi ID'ye sahip olduklarını kanıtlayan bir ZK-SNARK üreterek işlem gönderebilir.

![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-2439f49163d0212333ea4207f34cdbef.webp(

Bu eklemeyle birlikte, artık geniş bir seçeneğe sahibiz ve ZK paketli merkezi kimlik, benzersiz bir "yeni başlayan dostluğu" sunuyor.

Bunu başarmak için, basit ve entegre bir UI aracılığıyla gerçekleştirilmesi gerekiyor: Kullanıcı, yalnızca "example@gmail.com" adresini vasisi olarak belirtmelidir ve bu, otomatik olarak ilgili zk-email Ethereum adresini arka planda oluşturmalıdır. İleri düzey kullanıcılar, e-posta adreslerini ) ve bu e-posta adresinde saklanabilecek gizlilik tuzlarını ( açık kaynaklı üçüncü taraf uygulamalarına girebilmeli ve oluşturulan adresin doğru olduğunu onaylayabilmelidir. Diğer desteklenen vasi türleri için de bu şekilde olmalıdır.

Lütfen dikkat edin, günümüzde zk-email'in karşılaştığı bir gerçek sorun, DKIM imzasına bağımlılığıdır; bu imza birkaç ayda bir değiştirilen anahtarlar kullanmaktadır ve bu anahtarlar kendileri başka bir kuruluş tarafından imzalanmamıştır. Bu, günümüzde zk-email'in sağlayıcının kendisinden daha fazla bir güven düzeyine sahip olduğu anlamına gelir; eğer zk-email, güncellenmiş anahtarları doğrulamak için güvenilir donanım içinde TLSNotary kullanırsa, bu durum azaltılabilir, ancak bu ideal değildir. Umuyoruz ki e-posta sağlayıcıları, DKIM anahtarlarını doğrudan imzalamaya başlayabilirler. Bugün, bir denetleyiciye zk-email kullanması önerilmektedir, ancak çoğu denetleyiciye önerilmemektedir: zk-email'de depolanan fonların bozulması, kullanıcıların fonlara erişememesi anlamına gelir.

![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(

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özetmen girmek istemiyor. Bu nedenle, cüzdan onlara çok basit bir seçenek sunmalıdır. Doğal bir yol, e-posta adresinde zk-email kullanmak, kullanıcı cihazında yerel olarak depolanan anahtar )'in evrensel anahtar ( olabileceği ve sağlayıcı tarafından tutulan yedek anahtar ile 2-of-3 seçeneği sağlamaktır. Kullanıcı daha deneyimli hale geldikçe veya daha fazla varlık biriktirdikçe, bir noktada onlara daha fazla gözetmen eklemeleri için bir uyarı yapılmalıdır.

Cüzdanın uygulamalara 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 ) uygulaması yüklemelerini istemez, ayrıca Ethereum cüzdanı ( karmaşık bir kullanıcı deneyimi yaratır. Ancak, birçok uygulama cüzdanının kullanıcıları tüm cüzdanlarını bir araya getirebilmelidir, böylece tek bir "erişim kontrol sorunu" ile ilgilenmeleri gerekir. En basit yöntem, kullanıcıların ana cüzdanlarını tüm uygulama içi cüzdanların gözlemcisi olarak ayarlamalarına izin veren hızlı bir "bağlantı" süreci içeren katmanlı bir yaklaşım benimsemektir. Bazı istemciler bunu zaten desteklemektedir.

Varsayılan olarak, kullanıcıların bazı uygulama içi hesaplarının kurtarımı uygulama geliştirme ekibi tarafından kontrol edilebilir. Ancak, kullanıcı "kendi" hesaplarını devralabilir ve kurtarmayı kendi adresine değiştirebilir.

![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-ab5913a80a4549d9fec805c19442956b.webp(

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

Hesap güvenliğinin yanı sıra, günümüz cüzdanları yanıltıcı adresleri, kimlik avını, dolandırıcılığı ve diğer dış tehditleri tanımlamak için de çok şey yapıyor ve kullanıcıları bu tür tehditlerden korumak için çaba sarf ediyor. Bu arada, birçok önlem hala oldukça ilkel: örneğin, kullanıcının 100 dolar göndermesi önemli olmaksızın, ETH veya diğer token'ları herhangi bir yeni adrese gönderebilmesi için tıklama gerekliliği.