Dan Finlay, Karl Floersch, David Hoffman ve Scroll ve SoulWallet ekiplerine geri bildirim, inceleme ve önerileri için özel teşekkürler.

Ethereum genç bir deneysel teknolojiden ortalama kullanıcılara açık, küresel ve izinsiz bir deneyim sunabilen olgun bir teknoloji yığınına dönüşürken, yığının kabaca eş zamanlı olarak geçirmesi gereken üç büyük teknik geçiş vardır:

• L2 ölçeklendirme geçişi - herkes rollup'lara geçiyor
• Cüzdan güvenliği geçişi - herkes akıllı sözleşme cüzdanlarınageçiyor
• Gizlilik geçişi - gizliliği koruyan fon transferlerinin mevcut olduğundan emin olmak ve geliştirilmekte olan diğer tüm araçların (sosyal kurtarma, kimlik, itibar) gizliliği koruduğundan emin olmak

Ekosistem geçiş üçgeni. 3'ten sadece 3'ünü seçebilirsiniz.

İlki olmadan Ethereum başarısız olur çünkü her işlem 3,75 dolara mal olur (bir boğa koşusu daha yaparsak 82,48 dolar) ve kitlesel pazarı hedefleyen her ürün kaçınılmaz olarak zinciri unutur ve her şey için merkezi geçici çözümler benimser.

İkincisi olmadan Ethereum başarısız olur çünkü kullanıcılar fonlarını (ve finansal olmayan varlıklarını) saklamaktan rahatsız olur ve herkes merkezi borsalara geçer.

Üçüncüsü olmadan, Ethereum başarısız olur çünkü tüm işlemlerin (ve POAP'ların vb.) kelimenin tam anlamıyla herkesin görebileceği şekilde halka açık olması, birçok kullanıcı için çok yüksek bir gizlilik fedakarlığıdır ve herkes verilerinizi en azından bir şekilde gizleyen merkezi çözümlere geçer.

Bu üç geçiş yukarıdaki nedenlerden dolayı çok önemlidir. Ancak aynı zamanda, uygun şekilde çözüme kavuşturulmaları için gereken yoğun koordinasyon nedeniyle de zorlayıcıdırlar. Geliştirilmesi gereken sadece protokolün özellikleri değil; bazı durumlarda Ethereum ile etkileşim şeklimizin oldukça temelden değişmesi gerekiyor, bu da uygulamalarda ve cüzdanlarda derin değişiklikler gerektiriyor.

Üç geçiş, kullanıcılar ve adresler arasındaki ilişkiyi kökten yeniden şekillendirecek

L2 ölçeklendirme dünyasında, kullanıcılar çok sayıda L2'de bulunacaktır. İyimserlikle yaşayan ExampleDAO'nun bir üyesi misiniz? O zaman Optimism'de bir hesabınız var! ZkSync üzerinde bir stablecoin sisteminde CDP tutuyor musunuz? O zaman ZkSync'te bir hesabınız var! Bir keresinde gidip Kakarot'ta yaşayan bir uygulamayı denediniz mi? O zaman Kakarot'ta bir hesabınız var! Bir kullanıcının yalnızca tek bir adrese sahip olduğu günler geride kalacak.

Brave Wallet görünümüme göre dört yerde ETH'm var. Ve evet, Arbitrum ve Arbitrum Nova farklıdır. Merak etmeyin, zamanla daha da kafa karıştırıcı olacak!

Akıllı sözleşme cüzdanları, L1 ve çeşitli L2'lerde aynı adrese sahip olmayı çok daha zor hale getirerek daha fazla karmaşıklık ekler. Günümüzde çoğu kullanıcı, adresi tam anlamıyla imzaları doğrulamak için kullanılan genel anahtarın bir karması olan harici olarak sahip olunan hesapları kullanmaktadır - bu nedenle L1 ve L2 arasında hiçbir şey değişmez. Ancak akıllı sözleşme cüzdanlarında tek bir adres tutmak daha zor hale gelir. CREATE2 ve ERC-2470 singleton fabrikası başta olmak üzere, adresleri ağlar arasında eşdeğer olabilecek kod karmaları haline getirmeye çalışmak için birçok çalışma yapılmış olsa da, bunun mükemmel bir şekilde çalışmasını sağlamak zordur. Bazı L2'ler (örn. "tip 4 ZK-EVM'ler") tam olarak EVM eşdeğeri değildir, genellikle bunun yerine Solidity veya bir ara montaj kullanır ve hash eşdeğerliğini önler. Ve hash eşdeğerliğine sahip olsanız bile, cüzdanların anahtar değişiklikleri yoluyla sahiplik değiştirme olasılığı başka sezgisel olmayan sonuçlar yaratır.

Gizlilik, her kullanıcının daha da fazla adrese sahip olmasını gerektirir ve hatta ne tür adreslerle uğraştığımızı bile değiştirebilir. Gizli adres önerileri yaygın olarak kullanılırsa, her kullanıcının yalnızca birkaç adresi veya L2 başına bir adresi olması yerine, kullanıcılar işlem başına bir adrese sahip olabilir. Diğer gizlilik planları, hatta Tornado Cash gibi mevcut olanlar bile, varlıkların nasıl saklandığını farklı bir şekilde değiştirir: birçok kullanıcının fonları aynı akıllı sözleşmede (ve dolayısıyla aynı adreste) saklanır. Belirli bir kullanıcıya fon göndermek için kullanıcıların gizlilik planının kendi dahili adresleme sistemine güvenmeleri gerekecektir.

Gördüğümüz gibi, üç geçişin her biri "bir kullanıcı ~= bir adres" zihinsel modelini farklı şekillerde zayıflatmaktadır ve bu etkilerden bazıları geçişlerin yürütülmesinin karmaşıklığına geri dönmektedir. Karmaşıklığın iki özel noktası vardır:

1. Birine ödeme yapmak istiyorsanız, nasıl ödeme yapacağınıza dair bilgiyi nasıl alacaksınız?
2. Kullanıcılar farklı zincirlerde farklı yerlerde depolanan çok sayıda varlığa sahipse, anahtar değişiklikleri ve sosyal kurtarma işlemlerini nasıl yaparlar?

Üç geçiş ve zincir içi ödemeler (ve kimlik)

Scroll'da bozuk param var ve kahve için ödeme yapmak istiyorum ("Ben" kelimenin tam anlamıyla ben, bu makalenin yazarıysam, o zaman "kahve" elbette "yeşil çay" için bir metonimidir). Bana kahve satıyorsunuz ama sadece Taiko'dan para almak için ayarlanmışsınız. Ne yapalım?

Temelde iki çözüm vardır:

1. Alıcı cüzdanlar (tüccarlar olabileceği gibi sıradan bireyler de olabilir) her L2'yi desteklemek için gerçekten çok çalışır ve fonları eşzamansız olarak birleştirmek için bazı otomatik işlevlere sahiptir.
2. Alıcı, adresinin yanı sıra L2'sini de verir ve göndericinin cüzdanı, bazı çapraz L2 köprüleme sistemi aracılığıyla fonları otomatik olarak hedef L2'ye yönlendirir.

Elbette bu çözümler birleştirilebilir: alıcı, kabul etmek istediği L2'lerin listesini sağlar ve göndericinin cüzdanı, şanslıysa doğrudan bir gönderimi veya aksi takdirde L2'ler arası bir köprüleme yolunu içerebilecek ödemeyi hesaplar.

Ancak bu, üç geçişin getirdiği temel zorluklardan yalnızca bir tanesidir: birine ödeme yapmak gibi basit eylemler, 20 baytlık bir adresten çok daha fazla bilgi gerektirmeye başlar.

Akıllı sözleşme cüzdanlarına geçiş neyse ki adresleme sistemi üzerinde büyük bir yük oluşturmuyor, ancak uygulama yığınının diğer bölümlerinde hala üzerinde çalışılması gereken bazı teknik sorunlar var. Cüzdanların bir işlemle birlikte yalnızca 21000 gaz göndermediklerinden emin olmak için güncellenmesi gerekecek ve bir cüzdanın ödeme alan tarafının yalnızca EOA'lardan ETH transferlerini değil, aynı zamanda akıllı sözleşme kodu ile gönderilen ETH'yi de izlemesini sağlamak daha da önemli olacaktır. Adres sahipliğinin değişmez olduğu varsayımına dayanan uygulamalar (örn. Telif haklarını uygulamak için akıllı sözleşmeleri yasaklayan NFT'ler) hedeflerine ulaşmak için başka yollar bulmak zorunda kalacaktır. Akıllı sözleşme cüzdanları da bazı şeyleri kolaylaştıracaktır - özellikle, birisi yalnızca ETH olmayan bir ERC20 jetonu alırsa, bu jetonla gaz için ödeme yapmak üzere ERC-4337 ödeme yönetic ilerini kullanabilecektir.

Öte yandan, mahremiyet bir kez daha henüz tam olarak üstesinden gelemediğimiz büyük zorluklar ortaya çıkarmaktadır. Orijinal Tornado Cash, dahili transferleri desteklemediği için bu sorunların hiçbirini ortaya çıkarmadı: kullanıcılar yalnızca sisteme para yatırabilir ve sistemden para çekebilirdi. Ancak dahili transferler yapabildiğinizde, kullanıcıların gizlilik sisteminin dahili adresleme şemasını kullanmaları gerekecektir. Uygulamada, bir kullanıcının "ödeme bilgilerinin" hem (i) alıcının harcama yapmak için kullanabileceği bir sır taahhüdü olan bir tür "harcama pubkey" içermesi hem de (ii) göndericinin, alıcının ödemeyi keşfetmesine yardımcı olmak için yalnızca alıcının şifresini çözebileceği şifreli bilgiler göndermesinin bir yolu olması gerekir.

Gizli adres protokolleri şu şekilde çalışan bir meta-adres kavramına dayanır: meta-adresin bir kısmı gönderenin harcama anahtarının körleştirilmiş bir versiyonudur ve diğer kısmı gönderenin şifreleme anahtarıdır (minimal bir uygulama bu iki anahtarı aynı olacak şekilde ayarlayabilir).

Şifreleme ve ZK-SNARK'lara dayalı soyut bir gizli adres şemasına şematik genel bakış.

Buradan çıkarılacak en önemli ders, gizlilik dostu bir ekosistemde bir kullanıcının hem harcama pubkeylerine hem de şifreleme pubkeylerine sahip olacağı ve bir kullanıcının "ödeme bilgilerinin" her iki anahtarı da içermesi gerekeceğidir. Bu yönde genişlemek için ödemeler dışında da iyi nedenler var. Örneğin, Ethereum tabanlı şifrelenmiş e-posta istiyorsak, kullanıcıların bir tür şifreleme anahtarını herkese açık olarak sağlamaları gerekecektir. "EOA dünyasında", bunun için hesap anahtarlarını yeniden kullanabiliriz, ancak güvenli bir akıllı sözleşme-cüzdan dünyasında, muhtemelen bunun için daha açık bir işlevselliğe sahip olmalıyız. Bu aynı zamanda Ethereum tabanlı kimliğin, başta PGP anahtarları olmak üzere Ethereum dışı merkezi olmayan gizlilik ekosistemleriyle daha uyumlu hale getirilmesine de yardımcı olacaktır.

Üç geçiş ve kilit iyileşme

Kullanıcı başına çok sayıda adresin bulunduğu bir dünyada anahtar değişikliklerini ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcıların kurtarma prosedürünü her adreste ayrı ayrı çalıştırmasını sağlamaktır. Bu tek bir tıklamayla yapılabilir: cüzdan, kurtarma prosedürünü bir kullanıcının tüm adreslerinde aynı anda yürütmek için bir yazılım içerebilir. Bununla birlikte, bu tür kullanıcı deneyimi basitleştirmeleriyle bile, naif çoklu adres kurtarma işleminin üç sorunu vardır:

1. Gaz maliyetinin pratik olmaması: Bu durum kendini açıklamaktadır.
2. Karşı olgusal adresler: akıllı sözleşmenin henüz yayınlanmadığı adresler (pratikte bu, henüz para göndermediğiniz bir hesap anlamına gelecektir). Bir kullanıcı olarak potansiyel olarak sınırsız sayıda karşı olgusal adrese sahipsiniz: henüz var olmayan L2'ler de dahil olmak üzere her L2'de bir veya daha fazla ve gizli adres şemalarından kaynaklanan sonsuz sayıda karşı olgusal adres.
3. Gizlilik: Bir kullanıcı, birbirleriyle ilişkilendirmekten kaçınmak için kasıtlı olarak çok sayıda adrese sahipse, kesinlikle hepsini aynı anda veya yaklaşık olarak kurtararak herkese açık bir şekilde ilişkilendirmek istemez!

Bu sorunları çözmek zordur. Neyse ki, oldukça iyi performans gösteren zarif bir çözüm var: doğrulama mantığını ve varlık varlıklarını ayıran bir mimari.

Her kullanıcının tek bir konumda (ana ağ veya belirli bir L2 olabilir) bulunan bir anahtar deposu sözleşmesi vardır. Kullanıcıların farklı L2'lerde adresleri vardır ve bu adreslerin her birinin doğrulama mantığı anahtar deposu sözleşmesine bir işaretçidir. Bu adreslerden yapılan harcamalar, anahtar deposu sözleşmesine girerek mevcut (veya daha gerçekçi bir ifadeyle çok yakın tarihli) harcama açık anahtarını gösteren bir kanıt gerektirecektir.

Kanıt birkaç şekilde uygulanabilir:

• L2 içinde doğrudan salt okunur L1 erişimi. L2'leri, L1 durumunu doğrudan okuyabilecekleri şekilde değiştirmek mümkündür. Anahtar deposu sözleşmesi L1 üzerindeyse, bu L2 içindeki sözleşmelerin anahtar deposuna "ücretsiz" olarak erişebileceği anlamına gelir
• Merkle şubeleri. Merkle dalları L1 durumunu bir L2'ye veya L2 durumunu bir L1'e kanıtlayabilir veya bir L2'nin durumunun bazı kısımlarını başka bir L2'ye kanıtlamak için ikisini birleştirebilirsiniz. Merkle ispatlarının temel zayıflığı, ispat uzunluğu nedeniyle yüksek gaz maliyetleridir: bir ispat için potansiyel olarak 5 kB, ancak bu gelecekte Verkle ağaçları nedeniyle < 1 kB'ye düşecektir.
• ZK-SNARK'lar. Dalın kendisi yerine bir Merkle dalının ZK-SNARK'ını kullanarak veri maliyetlerini azaltabilirsiniz. Tek bir ZK-SNARK'ın bir bloktaki tüm zincirler arası durum kanıtlarını doğrulamasını sağlamak için zincir dışı birleştirme teknikleri (örneğin EIP-4337'nin üzerine) oluşturmak mümkündür.
• KZG taahhütleri. L2'ler ya da bunların üzerine inşa edilen şemalar, sıralı bir adresleme sistemi getirebilir ve bu sistem içindeki durum kanıtlarının yalnızca 48 bayt uzunluğunda olmasına izin verebilir. ZK-SNARK'larda olduğu gibi, bir çoklu ispat şeması tüm bu ispatları blok başına tek bir ispatta birleştirebilir.

İşlem başına bir ispat yapmaktan kaçınmak istiyorsak, kurtarma için yalnızca çapraz L2 ispatı gerektiren daha hafif bir şema uygulayabiliriz. Bir hesaptan harcama yapmak, ilgili pubkey'i o hesapta saklanan bir harcama anahtarına bağlı olacaktır, ancak kurtarma işlemi, anahtar deposundaki mevcut spending_pubkey'i kopyalayan bir işlem gerektirecektir. Eski anahtarlarınız güvende olmasa bile karşı olgusal adreslerdeki fonlar güvendedir: Bir karşı-olgusal adresi çalışan bir sözleşmeye dönüştürmek için "etkinleştirmek", mevcut spending_pubkey'i kopyalamak için çapraz L2 kanıtı yapmayı gerektirir. Safe forumlarındaki bu başlık benzer bir mimarinin nasıl çalışabileceğini açıklamaktadır.

Böyle bir şemaya gizlilik eklemek için, sadece işaretçiyi şifreleriz ve tüm kanıtlarımızı ZK-SNARK'ların içinde yaparız:

Daha fazla çalışma ile (örn. <a href="https://notes.ethereum.org/@vbuterin/non_index_revealing_proof"> this kullanarak bir başlangıç noktası olarak), ZK-SNARK'ların karmaşıklığının çoğunu çıkarabilir ve daha çıplak kemikli bir KZG tabanlı şema yapabiliriz.

Bu planlar karmaşık hale gelebilir. İşin iyi tarafı, aralarında pek çok potansiyel sinerji bulunmaktadır. Örneğin, "anahtar deposu sözleşmeleri" kavramı, bir önceki bölümde bahsedilen "adresler" sorununa da bir çözüm olabilir: kullanıcıların her anahtar güncellemesinde değişmeyen kalıcı adreslere sahip olmasını istiyorsak, gizli meta adresleri, şifreleme anahtarlarını ve diğer bilgileri anahtar deposu sözleşmesine koyabilir ve anahtar deposu sözleşmesinin adresini bir kullanıcının "adresi" olarak kullanabiliriz.

Çok sayıda ikincil altyapının güncellenmesi gerekiyor

ENS kullanmak pahalıdır. Bugün, Haziran 2023'te durum çok kötü değil: işlem ücreti önemli, ancak yine de ENS alan adı ücretiyle karşılaştırılabilir. Zuzalu.eth'yi kaydettirmek bana 11 doları işlem ücreti olmak üzere yaklaşık 27 dolara mal oldu. Ancak bir boğa piyasası daha yaşarsak, ücretler hızla yükselecektir. ETH fiyat artışları olmasa bile, 200 gwei'ye dönen gaz ücretleri, bir alan adı kaydının tx ücretini 104 dolara çıkaracaktır. Dolayısıyla, insanların ENS'yi gerçekten kullanmasını istiyorsak, özellikle de kullanıcıların neredeyse ücretsiz kayıt talep ettiği merkezi olmayan sosyal medya gibi kullanım durumları için (ve ENS alan adı ücreti bir sorun değil çünkü bu platformlar kullanıcılarına alt alan adları sunuyor), ENS'nin L2 üzerinde çalışmasına ihtiyacımız var.

Neyse ki ENS ekibi adım attı ve ENS on L2 gerçekten gerçekleşiyor! ERC-3668 (diğer adıyla "CCIP standardı"), ENSIP-10 ile birlikte, herhangi bir L2 üzerindeki ENS alt alan adlarının otomatik olarak doğrulanabilir olması için bir yol sağlar. CCIP standardı, L2 üzerindeki verilerin kanıtlarını doğrulamak için bir yöntem tanımlayan bir akıllı sözleşme ve bir etki alanı (örn. Optinames ecc.eth kullanır) böyle bir sözleşmenin kontrolü altına alınabilir. CCIP sözleşmesi L1 üzerinde ecc.eth'yi kontrol ettiğinde, ecc.eth alt alan adına erişmek otomatik olarak bir kanıt bulmayı ve doğrulamayı içerecektir (örn. Merkle dalı) L2'de o belirli alt etki alanını gerçekten depolayan durum.

Aslında kanıtları almak, sözleşmede depolanan URL'lerin bir listesine gitmeyi içerir, bu da kuşkusuz merkezileştirme gibi hissettirir, ancak bunun gerçekten olmadığını iddia ediyorum: bu bir 1-of-N güven modelidir (geçersiz kanıtlar, CCIP sözleşmesinin geri arama işlevindeki doğrulama mantığı tarafından yakalanır ve URL'lerden biri bile geçerli bir kanıt döndürdüğü sürece, iyisinizdir). URL'lerin listesi düzinelerce içerebilir.

ENS CCIP çalışması bir başarı öyküsüdür ve ihtiyacımız olan türden radikal reformların gerçekten mümkün olabileceğinin bir işareti olarak görülmelidir. Ancak uygulama katmanında yapılması gereken çok daha fazla reform var. Birkaç örnek:

• Pek çok dapp, kullanıcıların zincir dışı imzalar sağlamasına bağlıdır. Harici olarak sahip olunan hesaplar (EOA'lar) ile bu kolaydır. ERC-1271, akıllı sözleşme cüzdanları için bunu yapmanın standartlaştırılmış bir yolunu sağlar. Bununla birlikte, birçok dapp hala ERC-1271'i desteklemiyor; desteklemeleri gerekecek.
• Kullanıcılar ve sözleşmeler arasında ayrımcılık yapmak için "bu bir EOA mı?" sorusunu kullanan Dapp'ler (örneğin, devri önlemek veya telif ücretlerini uygulamak için) kırılacaktır. Genel olarak, burada tamamen teknik bir çözüm bulmaya çalışmamanızı tavsiye ederim; belirli bir kriptografik kontrol transferinin intifa hakkı transferi olup olmadığını anlamak zor bir sorundur ve muhtemelen zincir dışı topluluk güdümlü mekanizmalara başvurmadan çözülemez. Büyük olasılıkla, uygulamalar transferleri önlemeye daha az ve Harberger vergileri gibi tekniklere daha fazla güvenmek zorunda kalacaktır.
• Cüzdanların harcama ve şifreleme anahtarları ile etkileşiminin iyileştirilmesi gerekecektir. Şu anda, cüzdanlar uygulamaya özel anahtarlar oluşturmak için genellikle deterministik imzalar kullanmaktadır: bir EOA'nın özel anahtarı ile standart bir nonce (örneğin, uygulamanın adının karması) imzalamak, özel anahtar olmadan üretilemeyen deterministik bir değer üretir ve bu nedenle tamamen teknik anlamda güvenlidir. Ancak bu teknikler cüzdan için "opaktır" ve cüzdanın kullanıcı arayüzü düzeyinde güvenlik kontrolleri uygulamasını engeller. Daha olgun bir ekosistemde, imzalama, şifreleme ve ilgili işlevlerin cüzdanlar tarafından daha açık bir şekilde ele alınması gerekecektir.
• Hafif müşteriler (örn. Helios) sadece L1'i değil L2'leri de doğrulamak zorunda kalacaktır. Günümüzde hafif istemciler, L1 başlıklarının geçerliliğini kontrol etmeye (hafif istemci senkronizasyon protokolünü kullanarak) ve L1 durumunun Merkle dallarını ve L1 başlığında köklenen işlemleri doğrulamaya odaklanmaktadır. Yarın, L1'de depolanan durum köküne dayanan L2 durumunun bir kanıtını da doğrulamaları gerekecektir (bunun daha gelişmiş bir versiyonu aslında L2 ön onaylarına bakacaktır).

Cüzdanların hem varlıkları hem de verileri güvence altına alması gerekecek

Günümüzde cüzdanlar, varlıkları güvence altına alma işindedir. Her şey zincir üzerinde yaşar ve cüzdanın koruması gereken tek şey o anda bu varlıkları koruyan özel anahtardır. Anahtarı değiştirirseniz, önceki özel anahtarınızı ertesi gün güvenli bir şekilde internette yayınlayabilirsiniz. Ancak ZK dünyasında bu artık geçerli değildir: cüzdan yalnızca kimlik doğrulama bilgilerini korumakla kalmaz, aynı zamanda verilerinizi de tutar.

Böyle bir dünyanın ilk işaretlerini Zuzalu'da kullanılan ZK-SNARK tabanlı kimlik sistemi Zupass ile gördük. Kullanıcılar, sistemde kimlik doğrulaması yapmak için kullandıkları özel bir anahtara sahipti ve bu anahtar, "hangisi olduğunu açıklamadan Zuzalu sakini olduğumu kanıtla" gibi temel kanıtlamalar yapmak için kullanılabiliyordu. Ancak Zupass sisteminin üzerine, başta pullar (Zupass'ın POAP versiyonu) olmak üzere başka uygulamalar da inşa edilmeye başlandı.

Kedi Takımı'nın gururlu bir üyesi olduğumu teyit eden çok sayıdaki Zupass damgalarımdan biri.

Damgaların POAP'lara göre sunduğu en önemli özellik, damgaların özel olmasıdır: verileri yerel olarak tutarsınız ve bir damgayı (ya da damgalar üzerinden yapılan bazı hesaplamaları) yalnızca sizin hakkınızda bu bilgilere sahip olmasını istediğiniz birine ZK ile kanıtlarsınız. Ancak bu ek bir risk yaratır: bu bilgiyi kaybederseniz pullarınızı da kaybedersiniz.

Elbette veri tutma sorunu tek bir şifreleme anahtarı tutma sorununa indirgenebilir: üçüncü bir taraf (hatta zincir) verinin şifrelenmiş bir kopyasını tutabilir. Bu, yaptığınız eylemlerin şifreleme anahtarını değiştirmemesi ve dolayısıyla şifreleme anahtarınızı güvende tutan sistemle herhangi bir etkileşim gerektirmemesi gibi kullanışlı bir avantaja sahiptir. Ancak yine de, şifreleme anahtarınızı kaybederseniz, her şeyi kaybedersiniz. Diğer taraftan, birisi şifreleme anahtarınızı görürse, bu anahtarla şifrelenmiş her şeyi görür.

Zupass'ın fiili çözümü, insanları anahtarlarını birden fazla cihazda saklamaya teşvik etmekti (örn. dizüstü bilgisayar ve telefon), çünkü tüm cihazlara aynı anda erişimlerini kaybetme olasılıkları çok düşüktür. Daha da ileri gidebilir ve anahtarı saklamak için birden fazla koruyucu arasında bölünmüş gizli paylaşım kullanabiliriz.

MPC aracılığıyla bu tür bir sosyal kurtarma, cüzdanlar için yeterli bir çözüm değildir, çünkü yalnızca mevcut vasilerin değil, aynı zamanda önceki vasilerin de varlıklarınızı çalmak için işbirliği yapabileceği anlamına gelir ki bu kabul edilemeyecek kadar yüksek bir risktir. Ancak gizlilik sızıntıları genellikle toplam varlık kaybından daha düşük bir risktir ve yüksek gizlilik gerektiren bir kullanım durumu olan biri, bu gizlilik gerektiren eylemlerle ilişkili anahtarı yedeklemeyerek her zaman daha yüksek bir kayıp riskini kabul edebilir.

Kullanıcıyı birden fazla kurtarma yolundan oluşan bizans sistemiyle boğmamak için, sosyal kurtarmayı destekleyen cüzdanların hem varlıkların kurtarılmasını hem de şifreleme anahtarlarının kurtarılmasını yönetmesi gerekecektir.

Kimliğe geri dön

Bu değişikliklerin ortak noktalarından biri, zincir üzerinde "sizi" temsil etmek için kullandığınız kriptografik bir tanımlayıcı olan "adres" kavramının kökten değişmesi gerekeceğidir. "Benimle nasıl etkileşime geçeceğinize dair talimatlar" artık sadece bir ETH adresi olmayacak; bir şekilde, birden fazla L2'deki birden fazla adresin, gizli meta adreslerin, şifreleme anahtarlarının ve diğer verilerin bir kombinasyonu olması gerekecek.

Bunu yapmanın bir yolu ENS'yi kimliğiniz haline getirmektir: ENS kaydınız tüm bu bilgileri içerebilir ve birine bob.eth (veya bob.ecc.eth, veya...), daha karmaşık alanlar arası ve gizliliği koruyan yollar da dahil olmak üzere, nasıl ödeme yapacakları ve sizinle nasıl etkileşimde bulunacakları hakkında her şeyi arayabilir ve görebilirler.

Ancak ENS merkezli bu yaklaşımın iki zayıf yönü vardır:

• İsminize çok fazla şey bağlıyor. İsminiz siz değilsiniz, isminiz size ait birçok özellikten biridir. Tüm kimlik profilinizin üzerinden geçmeden ve birçok uygulamada bir sürü kaydı güncellemeden adınızı değiştirmek mümkün olmalıdır.
• Güvenilir olmayan karşı olgusal isimlere sahip olamazsınız. Herhangi bir blok zincirinin temel UX özelliklerinden biri, henüz zincirle etkileşime girmemiş kişilere coin gönderebilmektir. Böyle bir işlevsellik olmadan, bir çıkmaz söz konusudur: zincirle etkileşim kurmak için işlem ücreti ödemek gerekir ki bu da... zaten coin sahibi olmayı gerektirir. CREATE2 ile akıllı sözleşme adresleri de dahil olmak üzere ETH adresleri bu özelliğe sahiptir. ENS isimleri bunu yapmaz, çünkü iki Bob da zincir dışında bob.ecc.eth olduklarına karar verirlerse, hangisinin ismi alacağını seçmenin bir yolu yok.

Olası bir çözüm, bu yazının başlarında mimaride bahsedilen anahtar deposu sözleşmesine daha fazla şey koymaktır. Anahtar deposu sözleşmesi, sizinle ilgili tüm çeşitli bilgileri ve sizinle nasıl etkileşim kurulacağını içerebilir (ve CCIP ile bu bilgilerin bir kısmı zincir dışı olabilir) ve kullanıcılar anahtar deposu sözleşmelerini birincil tanımlayıcıları olarak kullanırlar. Ancak aldıkları gerçek varlıklar her türlü farklı yerde saklanacaktır. Anahtar deposu sözleşmeleri bir isme bağlı değildir ve karşı olgu dostudur: kanıtlanabilir bir şekilde yalnızca belirli sabit başlangıç parametrelerine sahip bir anahtar deposu sözleşmesi tarafından başlatılabilen bir adres oluşturabilirsiniz.

Bir diğer çözüm kategorisi ise, Bitcoin ödeme protokolüne benzer bir şekilde, kullanıcıya yönelik adres kavramını tamamen terk etmekle ilgilidir. Bir fikir, gönderici ve alıcı arasındaki doğrudan iletişim kanallarına daha fazla güvenmektir; örneğin, gönderici, alıcının ödemeyi istediği şekilde kabul etmek için kullanabileceği bir talep bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir.

Göndericinin mi yoksa alıcının mı önce davrandığına bakılmaksızın, gerçek zamanlı olarak güncel ödeme bilgilerini doğrudan üreten cüzdanlara daha fazla güvenmek sürtüşmeyi azaltabilir. Bununla birlikte, kalıcı tanımlayıcılar kullanışlıdır (özellikle ENS ile) ve gönderici ile alıcı arasında doğrudan iletişim varsayımı pratikte gerçekten zor bir varsayımdır ve bu nedenle farklı tekniklerin bir kombinasyonunu görebiliriz.

Tüm bu tasarımlarda, işleri hem merkezi olmayan hem de kullanıcılar için anlaşılabilir tutmak çok önemlidir. Kullanıcıların mevcut varlıklarının ne olduğuna ve kendilerine yönelik hangi mesajların yayınlandığına dair güncel bir görünüme kolayca erişebilmelerini sağlamalıyız. Bu görüşler tescilli çözümlere değil, açık araçlara dayanmalıdır. Ödeme altyapısının daha karmaşık hale gelmesinin, geliştiricilerin neler olup bittiğini anlamakta ve yeni bağlamlara uyarlamakta zorlandığı opak bir "soyutlama kulesine" dönüşmesini önlemek için çok çalışmak gerekecek. Zorluklara rağmen, ölçeklenebilirlik, cüzdan güvenliği ve normal kullanıcılar için gizlilik sağlamak Ethereum'un geleceği için çok önemlidir. Bu sadece teknik fizibilite ile ilgili değil, normal kullanıcılar için gerçek erişilebilirlik ile ilgilidir. Bu zorluğun üstesinden gelmek için yükselmemiz gerekiyor.

Sorumluluk Reddi：

1. Bu makale[vitalik] adresinden yeniden basılmıştır, Tüm telif hakları orijinal yazar[Vitalik Buterin]'e aittir. Bu baskıya itirazınız varsa, lütfen Gate Learn ekibiyle iletişime geçin, onlar bu konuyu derhal ele alacaklardır.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve fikirler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirisi Gate Learn ekibi tarafından yapılmaktadır. Belirtilmediği sürece, çevrilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.