Ethereum, genç, deneysel bir teknolojiden sıradan kullanıcılara açık, küresel ve izinsiz bir deneyim sunabilen olgun bir teknoloji yığınına dönüşürken, aynı anda gerçekleşmesi gereken üç büyük teknolojik geçiş vardır:
Birincisi, L2 kapasite genişletme dönüşümü - herkes Rollup teknolojisine yöneliyor;
İkinci Cüzdan Güvenlik Dönüşümü - Herkes akıllı sözleşme cüzdanlarını kullanmaya başlar;
Üçüncüsü gizlilik dönüşümü - gizliliği koruyan para transferi işlevinin kullanılabilir olmasını sağlamak ve geliştirilmekte olan diğer tüm araçların (sosyal kurtarma, kimlik doğrulama, itibar vb.) gizliliği koruyucu olmasını sağlamak.
*Ethereum Ekosistem Dönüşüm Üçgeni. Sadece üçünü de seçebilirsiniz. *
İlk öğe olmadan, Ethereum başarısız olacak çünkü her işlemin maliyeti 3,75 ABD Doları (başka bir boğa koşusundan geçersek 82,48 ABD Doları) ve her kitlesel pazar ürünü kaçınılmaz olarak zincir içi Ticareti bırakacak ve merkezi bir çözüm benimseyecektir.
İkinci öğe olmadan, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolamak istemeyeceğinden ve herkes merkezi borsalara yöneleceğinden Ethereum başarısız olur.
Üçüncü öğe olmadan, Ethereum başarısız olur çünkü birçok kullanıcı için tüm işlemler (ve POAP vb.) herkes tarafından görülebilir, mahremiyetten fedakarlık çok büyük olur ve herkes en azından bir düzeyde gizli veri Merkezi çözümüne yönelir.
Yukarıda özetlenen nedenlerden dolayı, bu üç geçiş kritiktir. Ancak, ilgili koordinasyonun karmaşıklığından dolayı da zorlayıcıdırlar. Geliştirilmesi gereken sadece protokolün işlevselliği değil; bazı durumlarda, Ethereum ile etkileşim biçimimizin temelde ve derinden değişmesi gerekiyor, bu da uygulamalarda ve cüzdanlarda büyük değişiklikler gerektiriyor.
Bu üç dönüşüm, kullanıcılar ve adresler arasındaki ilişkiyi temelden yeniden şekillendirecek
L2 ölçekleme dünyasında, kullanıcılar birden fazla L2 ağında bulunacaktır. ExampleDAO üyesi misiniz? ExampleDAO, İyimserlik üzerinedir. O zaman Optimism'de bir hesabınız var! ZkSync'te bir stablecoin sisteminin CDP'sine sahip misiniz? O halde ZkSync'te bir hesabınız var! Hiç Kakarot'ta bulunan bazı uygulamaları denediniz mi? O halde Kakarot'ta bir hesabınız var! Kullanıcıların yalnızca bir adrese sahip olduğu günler geride kaldı.
*Cesur cüzdan görünümüm, Ethereum'u dört yerde tutuyorum. Evet, Arbitrum ve Arbitrum Nova farklıdır. Endişelenme, işler zamanla daha da karmaşıklaşacak! *
**Akıllı sözleşme cüzdanları, L1 ve çeşitli L2 ağlarında aynı adrese sahip olmayı zorlaştırdığından daha fazla karmaşıklık katar. **Günümüzde çoğu kullanıcı, adresleri aslında imzaları doğrulamak için kullanılan genel anahtarların karmaları olan, harici olarak sahip olunan hesapları kullanıyor - yani L1 ve L2 arasında hiçbir şey değişmiyor. Bununla birlikte, bir akıllı sözleşme cüzdanı kullanırken bir adresi korumak daha zor hale gelir. En önemlisi CREATE2 ve ERC-2470 tekil fabrika olmak üzere, farklı ağlarda eşdeğer bir kod karması oluşturmak için adresleri denemek ve yapmak için birçok çalışma yapılmış olsa da, bunu mükemmel bir şekilde başarmak zordur. Bazı L2 ağları (örneğin, "dördüncü türden ZK-EVM") EVM'lere tam olarak eşdeğer değildir ve genellikle karma eşdeğerleri yerine Solidity veya ara derleme dili kullanır. Hash denkliği elde edilebilse bile, cüzdanların önemli değişiklikler yoluyla sahipliğini değiştirme olasılığı daha az tahmin edilebilir başka sonuçlara yol açar.
**Gizlilik, kullanıcı başına daha fazla adres gerektirir ve hatta ele aldığımız adres türlerini değiştirebilir. **Gizli adres önerisi yaygın olarak kullanılıyorsa, kullanıcılar, kullanıcı başına yalnızca birkaç adres veya L2 ağı başına bir adres yerine işlem başına bir adrese sahip olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların farklı şekillerde saklanma şeklini 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 para göndermek için, kullanıcının gizlilik planının kendi dahili adresleme sistemine güvenmesi gerekecektir.
Gördüğümüz gibi, bu üç dönüşüm "tek kullanıcı ≈ tek adres" zihinsel modelini farklı şekillerde zayıflatır ve bu etkilerin bazıları da bu dönüşümleri gerçekleştirmenin karmaşıklığını artırır. Özellikle karmaşık konulardan ikisi:
**1. Birine ödeme yapmak isterseniz, ödeme bilgilerini nasıl alacaksınız? **
**2. Kullanıcılar varlıkları farklı zincirlerde farklı konumlarda depolarsa, temel değişiklikleri ve sosyal iyileşmeyi nasıl gerçekleştirirler? **
Bu üç geçiş ve zincir üstü ödemeler (ve kimlik)
Scroll'da jetonlarım var ve onları kahve satın almak için kullanmak istiyorum ("Ben" kelimesi bu makalenin yazarı Vitalik'e atıfta bulunuyorsa, o zaman "kahve" elbette "yeşil çay" anlamına gelir). Taiko'da kahve satıyorsunuz ama Taiko'da yalnızca jetonları kabul ediyorsunuz. ne yapalım?
Temel olarak iki çözüm vardır:
Alıcı cüzdan (bir tüccar veya sıradan bir birey olabilir) her L2'yi desteklemeye çalışır ve bazı eşzamansız fon birleştirme işlevlerine sahiptir.
Alacaklı, L2 bilgilerini adresin yanında sağlar ve gönderenin cüzdanı fonları otomatik olarak bir tür çapraz L2 köprüleme sistemi aracılığıyla hedef L2'ye yönlendirir.
Elbette bu çözümler bir arada kullanılabilir: Alacaklı, kabul etmek istedikleri L2 listesini sağlar ve gönderenin cüzdanı, doğrudan gönderilebilen (şans eseri) veya köprü yoluyla ödenebilen ödeme yöntemini belirler. L2.
Ancak bu, üç dönüşümün getirdiği temel zorluklardan yalnızca bir tanesidir: Basit ödeme davranışları, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Neyse ki, akıllı sözleşme cüzdanlarına geçmek adres sistemi üzerinde büyük bir yük değil, ancak uygulama yığınının diğer bölümlerinde çözülmesi gereken bazı teknik sorunlar var. İşlemleri gönderirken yalnızca 21000 gas göndermelerini sağlamak için cüzdanların güncellenmesi gerekiyor, aynı zamanda cüzdanın alıcı ucunun yalnızca EOA'dan ETH transferlerini değil, aynı zamanda ETH transferlerini de takip etmesini sağlamaya daha fazla dikkat edilmesi gerekiyor. akıllı sözleşme kodu Değişmez adres sahipliğine dayanan uygulamalar (örneğin, telif ücretlerini 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ıracak, özellikle de birisi yalnızca ETH olmayan ERC20 tokenlerini kabul ederse, bu jetonu kullanarak gas için ödeme yapmak için bir ERC-4337 paymaster kullanabilecek.
Öte yandan, mahremiyet konusu yine tam olarak çözemediğimiz büyük bir sorun. Orijinal Tornado Cash, dahili transferleri desteklemediği için bu sorunları ortaya çıkarmadı: kullanıcılar sisteme yalnızca para yatırabilir ve çekebilirdi. Ancak dahili aktarımlar mümkün olduğunda, kullanıcıların gizlilik sisteminin dahili adresleme şemasını kullanması gerekecektir. Uygulamada, bir kullanıcının "ödeme mesajının" (i) bir tür "harcama genel anahtarı", alıcının harcamak için kullanabileceği gizli bir taahhüt içermesi gerekir ve (ii) gönderen, yalnızca alıcının sahip olabileceği şifreli mesajlar gönderebilir. şifresini çözebilir Yardım alıcısı ödeme yöntemini keşfeder.
Stealth adres protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı gönderenin kandırılmış harcama anahtarıdır ve diğer kısmı gönderenin şifrelenmiş anahtarıdır (minimum bir uygulama her iki anahtarı da ayarlayabilir. aynı olmak).
Şifrelemeye ve ZK-SNARK'lara dayalı soyut gizli adres şemalarına genel bakış
Buradaki temel ders, **gizlilik dostu bir ekosistemde, kullanıcıların harcama ortak anahtarlarına ve şifreleme genel anahtarlarına sahip olacağı ve kullanıcıların "ödeme bilgilerinin" her iki anahtarı da içermesi gerekeceğidir. **Ödemenin yanı sıra, bu yönü genişletmek için başka iyi nedenler de var. Örneğin, Ethereum tabanlı şifrelenmiş e-postalar istiyorsak, kullanıcıların herkese açık bir şekilde bir tür şifreleme anahtarı sağlaması gerekir. "EOA dünyasında" hesap anahtarlarını yeniden kullanabiliriz, ancak güvenli akıllı sözleşme cüzdanları dünyasında muhtemelen bunun için daha açık işlevsellik sağlamalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, özellikle PGP anahtarları olmak üzere Ethereum olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu olmasına yardımcı olur.
Bu üç geçiş ve anahtar kurtarma
Her kullanıcının birden çok adresine sahip olduğu bir dünyada, temel değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcıların kurtarma işlemini her bir adres için ayrı ayrı çalıştırmasını sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdan, kurtarma işlemini kullanıcının tüm adreslerinde aynı anda gerçekleştirmek için bir yazılım işlevi sağlayabilir. Ancak, kullanıcı deneyiminin bu kadar basitleştirilmesine rağmen, çoklu adres kurtarmayla ilgili üç sorun vardır:
1. Benzin maliyeti gerçekçi değil: Bu apaçık ortada.
2. Karşı olgusal adresler: henüz bir akıllı sözleşme düzenlememiş olan adresler (aslında bu, henüz para göndermediğiniz hesaplar anlamına gelir). Bir kullanıcı olarak, sonsuz sayıda sanal adresiniz olabilir: henüz var olmayan L2'ler dahil olmak üzere her L2'de bir veya daha fazla ve gizli adres şemasından kaynaklanan sonsuz sayıda sanal adres kümesi.
3. Gizlilik: Bir kullanıcı kasıtlı olarak birden çok adresi birbirleriyle ilişkilendirmemek için kullanırsa, o zaman kesinlikle aynı anda veya yakın bir zamanda geri yükleyerek hepsini herkese açık bir şekilde ilişkilendirmek istemezler!
Bu sorunları çözmek zordur. Neyse ki oldukça iyi çalışan oldukça şık bir çözüm var: Bu mimari, doğrulama mantığını varlık tutmadan ayırır.
Her kullanıcının bir konumda bulunan bir anahtar deposu sözleşmesi vardır (ana ağ veya belirli bir L2 olabilir). Ardından, kullanıcıların farklı L2'lerde adresleri vardır ve her adres için doğrulama mantığı, anahtar deposu sözleşmesine yönelik bir işaretçidir. Bu adreslerden fon harcamak, fonlar için mevcut (veya daha gerçekçi olarak, çok yeni) bir harcama açık anahtarının kanıtını sağlamayı gerektirecektir.
Bu kanıt çeşitli şekillerde elde edilebilir:
** Doğrudan L2 içinden L1'e salt okunur erişim. ** L2, L1 durumunu doğrudan okumasını sağlamak için değiştirilebilir. Anahtar deposu sözleşmesi L1'deyse bu, L2'deki sözleşmelerin anahtar deposuna "ücretsiz" erişimi olduğu anlamına gelir.
**Merkle şubeleri. **Merkle dalları, L1 durumunu L2'ye veya L2 durumunu L1'e kanıtlayabilir veya her ikisinin bir kombinasyonu, bir L2'nin kısmi durumunu başka bir L2'ye kanıtlayabilir. Merkle ispatlarının ana zayıflığı, 5kB'lik bir ispat uzunluğu gerektirebilen ispat uzunluğu nedeniyle yüksek gaz maliyetidir, ancak Verkle ağaçlarının kullanılması nedeniyle bu, gelecekte <1kB'ye düşürülecektir.
**ZK-SNARK'lar. **Şubelerin kendilerini kullanmak yerine Merkle şubelerinin ZK-SNARK'larını kullanarak veri maliyetlerini düşürebilirsiniz. Tek bir ZK-SNARK'ın bir bloktaki tüm zincirler arası durum kanıtlarını doğrulamasını sağlamak için zincir dışı toplama teknikleri (örn. EIP-4337'nin üstünde) oluşturulabilir.
**KZG Sözü. **L2 veya onun üzerine inşa edilmiş şema olsun, sistem içindeki durum kanıtının yalnızca 48 bayt olmasına izin veren sıralı bir adresleme sistemi tanıtılabilir. ZK-SNARK'lar gibi, çoklu kanıt şemaları da tüm bu kanıtları her blok için tek bir kanıtta birleştirebilir.
Her işlem için bir kanıta ihtiyaç duymaktan kaçınmak istiyorsak, yalnızca L2 kanıtlarında kurtarma gerektiren daha hafif bir şema uygulayabiliriz. Bir hesaptan yapılan harcama, hesabın içinde saklanan karşılık gelen ortak anahtarıyla birlikte bir harcama anahtarına bağlı olacaktır, ancak kurtarma, geçerli harcama ortak anahtarını anahtar deposuna kopyalamak için bir işlem gerektirecektir. Eski anahtarlarınız güvenli olmasa bile, sanal adresteki fonlar güvendedir: sanal adresi kullanılabilir bir sözleşmeye dönüştürmek için "etkinleştirmek", geçerli harcanan ortak anahtarı çoğaltmak için L2 arası bir kanıt gerektirecektir. Güvenli forumlarda benzer bir mimarinin nasıl çalıştığını açıklayan bir başlık var.
Böyle bir şemaya gizlilik eklemek için yalnızca işaretçileri şifrelememiz ve tüm ispatları ZK-SNARK'ların içinde yapmamız yeterlidir:
Daha fazla çalışmayla (örn. ZK - SNARK'ların karmaşıklığının çoğu, daha basitleştirilmiş bir KZG tabanlı şema oluşturmak.
Bu senaryolar karmaşıklaşabilir. Olumlu tarafı, aralarında birçok potansiyel sinerji olmasıdır. Örneğin, bir "anahtar deposu sözleşmesi" kavramı, bir önceki bölümde bahsedilen "adres" için de bir çözüm olabilir: Kullanıcıların, anahtarı her güncellediğinde değişmeyen kalıcı bir adrese sahip olmasını istiyorsak, gizliliği koyabilir Meta adresi, şifreleme anahtarı ve diğer bilgiler anahtar deposu sözleşmesine konur ve anahtar deposu sözleşmesinin adresi, kullanıcının "adresi" olarak kullanılır.
Pek çok ikincil altyapının güncellenmesi gerekiyor
ENS kullanmak pahalıdır. Haziran 2023'te eskisi kadar pahalı olmasa da, bir alan adı kaydettirmek için işlem ücreti hala nispeten yüksektir ve bu, bir ENS alan adının maliyetiyle karşılaştırılabilir. Örneğin, zuzalu.eth'e kaydolmanın maliyeti yaklaşık 27 dolardır ve bunun 11 doları işlem ücretidir. Ancak piyasa yeniden yükselişe geçerse, ücretler artacaktır. ETH fiyatı artmasa bile gas ücreti 200 gwei'ye dönerse alan adı kaydı için işlem ücreti 104$'a ulaşacak. Dolayısıyla, insanların ENS'yi fiilen kullanmasını istiyorsak, özellikle de kullanıcıların neredeyse ücretsiz kayıt istediği merkezi olmayan sosyal medya gibi kullanım durumları için (bu platformlar kullanıcılara alt alan adları sağlayabildiğinden ENS alan ücretleri sorun değildir), ENS'nin şu alanlarda kullanılmasına ihtiyacımız var: katman 2.
Neyse ki, ENS ekibi çoktan hızlandı ve ENS, Katman 2'de uygulanıyor! ERC-3668 ("CCIP standardı" olarak da bilinir) ve ENSIP-10, herhangi bir Katman 2'deki ENS alt alanlarını otomatik olarak doğrulamak için bir yol sağlar. CCIP standardı, Katman 2'deki verilerin kanıtlarını doğrulama yöntemini açıklayan bir akıllı sözleşme kurulmasını gerektirir ve böyle bir sözleşmenin kontrolü altına bir alan adı (örneğin, Optimnames için ecc.eth) yerleştirilebilir. CCIP sözleşmesi L1'de ecc.eth'i kontrol ettikten sonra, belirli bir subdomain.ecc.eth'e erişim otomatik olarak o belirli alt alan adının (örn. bir Merkle şubesi) Katman 2 durumunu saklayan bir kanıtı bulur ve doğrular.
aslında bu kanıtları elde etmek, sözleşmede saklanan URL'lerin bir listesine erişmeyi içerir, ancak bu, Her nasılsa merkezileştirme gibi görünebilir, ancak öyle olmadığını söyleyebilirim: 1'den N'ye bir güven modeli (geçersiz kanıtlar, CCIP sözleşmesi geri arama işlevindeki doğrulama mantığı tarafından, A URL'sinden biri olduğu sürece yakalanacaktır. geçerli kanıt döndüren iyidir). URL listesi düzinelerce URL içerebilir.
**ENS'nin CCIP çabası bir başarı öyküsüdür ve ihtiyacımız olan radikal reformların gerçekten mümkün olduğunun bir işareti olarak görülmelidir. ** Ancak hala yapılması gereken uygulama düzeyinde birçok reform var. İşte bazı örnekler:
**Birçok DApp, zincir dışı imzalar sağlamak için kullanıcılara güvenir. **Harici Hesaplar (EOA) için kolaydır. ERC-1271, akıllı sözleşme cüzdanları için bunu yapmak için standartlaştırılmış bir yol sağlar. Ancak, birçok DApp hala ERC-1271'i desteklememektedir ve uyarlanmaları gerekmektedir.
** Kullanıcılar ve sözleşmeler arasında ayrım yapmak için (örneğin, transferleri önlemek veya telif ücretlerini uygulamak için) "bu bir EOA mı?" ** Genel olarak, burada tamamen teknik bir çözüm bulmaya çalışmamanızı tavsiye ederim; belirli bir kriptografik kontrol transferinin faydalı mülkiyet devri olup olmadığını belirlemek, bazı zincir dışı topluluk güdümlü yöntemlere başvurmadan çözülemeyecek zor bir sorundur. mekanizmalar çözer. Büyük olasılıkla, uygulamalar transferleri engellemenin teknik yollarına daha az ve Harberger vergisi gibi tekniklere daha çok güvenecektir.
**Ödemeler ve şifreleme anahtarlarıyla cüzdan etkileşiminin iyileştirilmesi gerekecek. **Şu anda, cüzdanlar genellikle uygulamaya özel anahtarlar oluşturmak için deterministik imzalar kullanır: EOA'nın özel anahtarıyla standart bir nonce (ör. üretilemez ve bu nedenle tamamen teknik olarak güvenlidir. Bununla birlikte, bu teknikler, cüzdan için "opak" olup, cüzdanların kullanıcı arabirimi 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 istemcilerin (Helios gibi) yalnızca Katman 1 yerine Katman 2'nin kimliğini doğrulaması gerekir**. **Şu anda, hafif istemci, L1 blok başlık bilgilerinin geçerliliğini kontrol etmeye (hafif istemci senkronizasyon protokolünü kullanarak) ve L1 durumunun Merkle dalını ve L1 blok başlık bilgilerine dayalı işlemleri doğrulamaya odaklanmıştır. Gelecekte, L1'de depolanan durum kökünde köklenen L2 durumunun kanıtlarını da doğrulamaları gerekecek (daha gelişmiş sürümler aslında L2 ön onayına bakacaktır).
Cüzdanların varlıkları ve verileri koruması gerekecek
Şu anda, cüzdanın görevi varlıkları korumaktır. Her şey zincirde saklanır, cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarı değiştirirseniz, önceki özel anahtarı ertesi gün güvenli bir şekilde internette herkese açık olarak gönderebilirsiniz. Ancak, sıfır bilgi dünyasında artık durum böyle değil: cüzdanlar yalnızca kimlik doğrulama bilgilerini korumakla kalmaz, aynı zamanda verilerinizi de tutar.
Böyle bir dünyanın ilk işaretlerini Zuzalu'da ZK-SNARK tabanlı bir kimlik sistemi olan Zupass ile görüyoruz. Kullanıcı, sisteme kimlik doğrulaması yapmak için kullanılan ve "hangi sakini olduğumu açıklamadan Zuzalu'da ikamet ettiğimi kanıtlamak" gibi temel kanıtları oluşturmak için kullanılabilen özel bir anahtara sahiptir. Zupass sistemi ayrıca, en önemlisi damgalar (Zupass'ın POAP versiyonu) olmak üzere başka uygulamalar oluşturmaya başladı.
*Cat Takımının bir üyesi olduğumu onaylayan birçok Zupass pulumdan biri. *
POAP'a göre damgaların temel özelliği, özel olmalarıdır: verileri yerel olarak tutarsınız ve bu bilgiyi birine vermek isterseniz yalnızca ZK'lerine bir damga kanıtlarsınız (veya damgalar üzerinde bazı hesaplamalar yaparsınız). Ancak bu aynı zamanda ek bir riski de beraberinde getirir: Bu bilgiyi kaybederseniz, pullarınızı da kaybedersiniz.
Tabii ki, veri tutma sorunu, tek bir şifreleme anahtarı tutma sorununa indirgenebilir: üçüncü bir taraf (zincirde bile) verilerin şifrelenmiş bir kopyasını tutabilir. Bu, yaptığınız işlemin şifreleme anahtarını değiştirmemesi ve dolayısıyla şifreleme anahtarını tutan sistemle herhangi bir etkileşime gerek olmaması gibi uygun bir avantaja sahiptir. Ancak o zaman bile, şifreleme anahtarını kaybederseniz tüm verilerinizi kaybedersiniz. Ayrıca, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilecek. **
Zupass'ın pratik çözümü, insanları anahtarlarını birden fazla cihazda (dizüstü bilgisayar ve telefon gibi) saklamaya teşvik etmektir, çünkü aynı anda hepsine erişimlerini kaybetme ihtimalleri çok düşüktür. Anahtar deposunu birden fazla koruyucu arasında bölmek için anahtar paylaşımını kullanarak bunu bir adım öteye götürebiliriz.
MPC yoluyla sosyal kurtarma, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut koruyucunun değil, aynı zamanda önceki koruyucuların da kabul edilemez derecede yüksek bir risk olan varlıklarınızı çalmak için işbirliği yapabileceği anlamına gelir. Bir gizlilik ihlali genellikle varlıkların tamamen kaybından daha az riskli olsa da, yüksek gizlilik gereksinimleri olan kullanım durumları için, bu gizlilik gereksinimleriyle ilişkili anahtarların yedeklenmemesiyle daha yüksek bir kayıp riski kabul edilebilir.
Kullanıcıları birden çok kurtarma yolundan oluşan karmaşık bir sistemde mahsur bırakmaktan kaçınmak için, sosyal kurtarmayı destekleyen cüzdanların varlık kurtarma ve şifreleme anahtarı kurtarmanın her iki yönünü de yönetmesi gerekebilir.
Kimliğe geri dön
Bu değişiklikler arasında ortak bir tema, blok zincirinde kimliğin bir temsili olarak bir "adres" kavramının temelden değişmesi gerekeceğidir. ** "Benimle nasıl etkileşime geçileceğine dair talimatlar" artık sadece bir ETH adresi olmayacak; ifade edin. **
Bu yollardan biri, kimliğiniz olarak ENS kullanmaktır: ENS kaydınız, nasıl ödeme yapacağınız ve sizinle nasıl etkileşim kuracağınızla ilgili tüm bilgileri içerebilir, birine bob.eth (veya bob.ecc.eth vb.) gönderirseniz, Sorgulayabilirler. ve etki alanları arasında daha karmaşık yollar ve gizlilik koruması da dahil olmak üzere sizinle etkileşime giren her şey hakkında bilgi edinin.
Ancak, bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
**Adınız ile çok fazla içerik ilişkilendirir. **İsminiz sizinle ilgili her şeyi ifade etmez, sizinle ilgili birçok özellikten yalnızca biridir. Birçok uygulamada tüm kimlik profilinizi taşımadan ve kayıtları güncellemeden adınızı değiştirmek mümkün olmalıdır.
**Güven gerektirmeyen karşı olgusal isimlere sahip olamazsınız. **Herhangi bir blok zincirinin önemli bir kullanıcı deneyimi özelliği, zincirle henüz etkileşime girmemiş kişilere jeton gönderme yeteneğidir. Böyle bir işlevsellik olmadan, bir ikilem vardır: zincirle etkileşim, işlem ücretlerinin ödenmesini gerektirir ve işlem ücretlerinin ödenmesi, zaten tokenlara sahip olmayı gerektirir. CREATE2 ile akıllı sözleşme adresleri dahil olmak üzere ETH adresleri bu işlevselliğe sahiptir. ENS adları yoktur, çünkü her iki Bob da bob.ecc.eth olduğuna zincir dışı karar verirse, hangi Bob'un adı alacağını seçmenin bir yolu yoktur.
Olası bir çözüm, bu makalenin mimarisinde daha önce bahsedilen anahtar deposu sözleşmesine daha fazla içerik koymaktır. Bir anahtar deposu sözleşmesi sizinle ve sizinle olan etkileşimlerle ilgili çeşitli bilgiler içerebilir (ve CCIP ile bu bilgilerin bir kısmı zincir dışı olabilir), kullanıcılar anahtar deposu sözleşmesini birincil tanımlayıcıları olarak kullanır. Ancak, fiilen aldıkları varlıklar çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri addan bağımsızdır ve sanal ad dostudur: yalnızca belirli sabit başlangıç parametrelerine sahip bir anahtar deposu sözleşmesi tarafından başlatılabilen bir adres oluşturabilirsiniz.
Başka bir çözüm sınıfı, Bitcoin'in ödeme protokolüne benzer şekilde, kullanıcıya yönelik adres kavramını tamamen terk etmeyi içerir. Bir fikir, gönderen ve alıcı arasındaki doğrudan iletişim kanallarına daha fazla güvenmektir; örneğin, gönderen, alıcının kabul etmek istediği herhangi bir isteği göndermek için kullanabileceği bir istek bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir. ödeme.
İlk hareket eden ister gönderen ister alıcı olsun, gerçek zamanlı olarak güncel ödeme bilgileri oluşturmak için cüzdanlara daha fazla güvenmek sürtünmeyi azaltır. Bununla birlikte, kalıcı tanımlayıcılar uygundur (özellikle ENS ile), oysa pratikte gönderici ve alıcı arasındaki doğrudan iletişime güvenmek çok zor bir problemdir, bu nedenle farklı tekniklerin bir kombinasyonu görülebilir.
Tüm bu tasarımlarda, merkezi olmayan ve kullanıcılar için anlaşılır kalmak çok önemlidir. Kullanıcıların mevcut varlıklarının ve onlara yönelik mesajların güncel bir görünümüne kolayca erişebilmelerini sağlamamız gerekiyor. Bu görüşler, özel çözümler yerine açık araçlara dayanmalıdır. Ödeme altyapısının karmaşıklığının anlaşılması ve yeni ortamlara uyarlanması zor olan opak bir "soyutlama kulesi" haline gelmesini önlemek için çok çalışmak gerekecek. Zorluklara rağmen, sıradan kullanıcılar için Ethereum'un ölçeklenebilirliğine, cüzdan güvenliğine ve gizliliğine ulaşmak çok önemlidir. Bu sadece teknik fizibilite ile ilgili değil, ortalama bir kullanıcı için gerçek erişilebilirlik ile ilgili. Bu zorluğun üstesinden gelmemiz gerekiyor.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Vitalik: Ethereum ekosisteminin üç teknolojik dönüşüme ihtiyacı var
Yazar: Vitalik, Ethereum'un kurucusu; Tercüme: Jinse Finance cryptonaitive
Ethereum, genç, deneysel bir teknolojiden sıradan kullanıcılara açık, küresel ve izinsiz bir deneyim sunabilen olgun bir teknoloji yığınına dönüşürken, aynı anda gerçekleşmesi gereken üç büyük teknolojik geçiş vardır:
*Ethereum Ekosistem Dönüşüm Üçgeni. Sadece üçünü de seçebilirsiniz. *
İlk öğe olmadan, Ethereum başarısız olacak çünkü her işlemin maliyeti 3,75 ABD Doları (başka bir boğa koşusundan geçersek 82,48 ABD Doları) ve her kitlesel pazar ürünü kaçınılmaz olarak zincir içi Ticareti bırakacak ve merkezi bir çözüm benimseyecektir.
İkinci öğe olmadan, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolamak istemeyeceğinden ve herkes merkezi borsalara yöneleceğinden Ethereum başarısız olur.
Üçüncü öğe olmadan, Ethereum başarısız olur çünkü birçok kullanıcı için tüm işlemler (ve POAP vb.) herkes tarafından görülebilir, mahremiyetten fedakarlık çok büyük olur ve herkes en azından bir düzeyde gizli veri Merkezi çözümüne yönelir.
Yukarıda özetlenen nedenlerden dolayı, bu üç geçiş kritiktir. Ancak, ilgili koordinasyonun karmaşıklığından dolayı da zorlayıcıdırlar. Geliştirilmesi gereken sadece protokolün işlevselliği değil; bazı durumlarda, Ethereum ile etkileşim biçimimizin temelde ve derinden değişmesi gerekiyor, bu da uygulamalarda ve cüzdanlarda büyük değişiklikler gerektiriyor.
Bu üç dönüşüm, kullanıcılar ve adresler arasındaki ilişkiyi temelden yeniden şekillendirecek
L2 ölçekleme dünyasında, kullanıcılar birden fazla L2 ağında bulunacaktır. ExampleDAO üyesi misiniz? ExampleDAO, İyimserlik üzerinedir. O zaman Optimism'de bir hesabınız var! ZkSync'te bir stablecoin sisteminin CDP'sine sahip misiniz? O halde ZkSync'te bir hesabınız var! Hiç Kakarot'ta bulunan bazı uygulamaları denediniz mi? O halde Kakarot'ta bir hesabınız var! Kullanıcıların yalnızca bir adrese sahip olduğu günler geride kaldı.
**Akıllı sözleşme cüzdanları, L1 ve çeşitli L2 ağlarında aynı adrese sahip olmayı zorlaştırdığından daha fazla karmaşıklık katar. **Günümüzde çoğu kullanıcı, adresleri aslında imzaları doğrulamak için kullanılan genel anahtarların karmaları olan, harici olarak sahip olunan hesapları kullanıyor - yani L1 ve L2 arasında hiçbir şey değişmiyor. Bununla birlikte, bir akıllı sözleşme cüzdanı kullanırken bir adresi korumak daha zor hale gelir. En önemlisi CREATE2 ve ERC-2470 tekil fabrika olmak üzere, farklı ağlarda eşdeğer bir kod karması oluşturmak için adresleri denemek ve yapmak için birçok çalışma yapılmış olsa da, bunu mükemmel bir şekilde başarmak zordur. Bazı L2 ağları (örneğin, "dördüncü türden ZK-EVM") EVM'lere tam olarak eşdeğer değildir ve genellikle karma eşdeğerleri yerine Solidity veya ara derleme dili kullanır. Hash denkliği elde edilebilse bile, cüzdanların önemli değişiklikler yoluyla sahipliğini değiştirme olasılığı daha az tahmin edilebilir başka sonuçlara yol açar.
**Gizlilik, kullanıcı başına daha fazla adres gerektirir ve hatta ele aldığımız adres türlerini değiştirebilir. **Gizli adres önerisi yaygın olarak kullanılıyorsa, kullanıcılar, kullanıcı başına yalnızca birkaç adres veya L2 ağı başına bir adres yerine işlem başına bir adrese sahip olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların farklı şekillerde saklanma şeklini 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 para göndermek için, kullanıcının gizlilik planının kendi dahili adresleme sistemine güvenmesi gerekecektir.
Gördüğümüz gibi, bu üç dönüşüm "tek kullanıcı ≈ tek adres" zihinsel modelini farklı şekillerde zayıflatır ve bu etkilerin bazıları da bu dönüşümleri gerçekleştirmenin karmaşıklığını artırır. Özellikle karmaşık konulardan ikisi:
**1. Birine ödeme yapmak isterseniz, ödeme bilgilerini nasıl alacaksınız? **
**2. Kullanıcılar varlıkları farklı zincirlerde farklı konumlarda depolarsa, temel değişiklikleri ve sosyal iyileşmeyi nasıl gerçekleştirirler? **
Bu üç geçiş ve zincir üstü ödemeler (ve kimlik)
Scroll'da jetonlarım var ve onları kahve satın almak için kullanmak istiyorum ("Ben" kelimesi bu makalenin yazarı Vitalik'e atıfta bulunuyorsa, o zaman "kahve" elbette "yeşil çay" anlamına gelir). Taiko'da kahve satıyorsunuz ama Taiko'da yalnızca jetonları kabul ediyorsunuz. ne yapalım?
Temel olarak iki çözüm vardır:
Alıcı cüzdan (bir tüccar veya sıradan bir birey olabilir) her L2'yi desteklemeye çalışır ve bazı eşzamansız fon birleştirme işlevlerine sahiptir.
Alacaklı, L2 bilgilerini adresin yanında sağlar ve gönderenin cüzdanı fonları otomatik olarak bir tür çapraz L2 köprüleme sistemi aracılığıyla hedef L2'ye yönlendirir.
Elbette bu çözümler bir arada kullanılabilir: Alacaklı, kabul etmek istedikleri L2 listesini sağlar ve gönderenin cüzdanı, doğrudan gönderilebilen (şans eseri) veya köprü yoluyla ödenebilen ödeme yöntemini belirler. L2.
Ancak bu, üç dönüşümün getirdiği temel zorluklardan yalnızca bir tanesidir: Basit ödeme davranışları, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Neyse ki, akıllı sözleşme cüzdanlarına geçmek adres sistemi üzerinde büyük bir yük değil, ancak uygulama yığınının diğer bölümlerinde çözülmesi gereken bazı teknik sorunlar var. İşlemleri gönderirken yalnızca 21000 gas göndermelerini sağlamak için cüzdanların güncellenmesi gerekiyor, aynı zamanda cüzdanın alıcı ucunun yalnızca EOA'dan ETH transferlerini değil, aynı zamanda ETH transferlerini de takip etmesini sağlamaya daha fazla dikkat edilmesi gerekiyor. akıllı sözleşme kodu Değişmez adres sahipliğine dayanan uygulamalar (örneğin, telif ücretlerini 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ıracak, özellikle de birisi yalnızca ETH olmayan ERC20 tokenlerini kabul ederse, bu jetonu kullanarak gas için ödeme yapmak için bir ERC-4337 paymaster kullanabilecek.
Öte yandan, mahremiyet konusu yine tam olarak çözemediğimiz büyük bir sorun. Orijinal Tornado Cash, dahili transferleri desteklemediği için bu sorunları ortaya çıkarmadı: kullanıcılar sisteme yalnızca para yatırabilir ve çekebilirdi. Ancak dahili aktarımlar mümkün olduğunda, kullanıcıların gizlilik sisteminin dahili adresleme şemasını kullanması gerekecektir. Uygulamada, bir kullanıcının "ödeme mesajının" (i) bir tür "harcama genel anahtarı", alıcının harcamak için kullanabileceği gizli bir taahhüt içermesi gerekir ve (ii) gönderen, yalnızca alıcının sahip olabileceği şifreli mesajlar gönderebilir. şifresini çözebilir Yardım alıcısı ödeme yöntemini keşfeder.
Stealth adres protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı gönderenin kandırılmış harcama anahtarıdır ve diğer kısmı gönderenin şifrelenmiş anahtarıdır (minimum bir uygulama her iki anahtarı da ayarlayabilir. aynı olmak).
Şifrelemeye ve ZK-SNARK'lara dayalı soyut gizli adres şemalarına genel bakış
Buradaki temel ders, **gizlilik dostu bir ekosistemde, kullanıcıların harcama ortak anahtarlarına ve şifreleme genel anahtarlarına sahip olacağı ve kullanıcıların "ödeme bilgilerinin" her iki anahtarı da içermesi gerekeceğidir. **Ödemenin yanı sıra, bu yönü genişletmek için başka iyi nedenler de var. Örneğin, Ethereum tabanlı şifrelenmiş e-postalar istiyorsak, kullanıcıların herkese açık bir şekilde bir tür şifreleme anahtarı sağlaması gerekir. "EOA dünyasında" hesap anahtarlarını yeniden kullanabiliriz, ancak güvenli akıllı sözleşme cüzdanları dünyasında muhtemelen bunun için daha açık işlevsellik sağlamalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, özellikle PGP anahtarları olmak üzere Ethereum olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu olmasına yardımcı olur.
Bu üç geçiş ve anahtar kurtarma
Her kullanıcının birden çok adresine sahip olduğu bir dünyada, temel değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcıların kurtarma işlemini her bir adres için ayrı ayrı çalıştırmasını sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdan, kurtarma işlemini kullanıcının tüm adreslerinde aynı anda gerçekleştirmek için bir yazılım işlevi sağlayabilir. Ancak, kullanıcı deneyiminin bu kadar basitleştirilmesine rağmen, çoklu adres kurtarmayla ilgili üç sorun vardır:
1. Benzin maliyeti gerçekçi değil: Bu apaçık ortada.
2. Karşı olgusal adresler: henüz bir akıllı sözleşme düzenlememiş olan adresler (aslında bu, henüz para göndermediğiniz hesaplar anlamına gelir). Bir kullanıcı olarak, sonsuz sayıda sanal adresiniz olabilir: henüz var olmayan L2'ler dahil olmak üzere her L2'de bir veya daha fazla ve gizli adres şemasından kaynaklanan sonsuz sayıda sanal adres kümesi.
3. Gizlilik: Bir kullanıcı kasıtlı olarak birden çok adresi birbirleriyle ilişkilendirmemek için kullanırsa, o zaman kesinlikle aynı anda veya yakın bir zamanda geri yükleyerek hepsini herkese açık bir şekilde ilişkilendirmek istemezler!
Bu sorunları çözmek zordur. Neyse ki oldukça iyi çalışan oldukça şık bir çözüm var: Bu mimari, doğrulama mantığını varlık tutmadan ayırır.
Her kullanıcının bir konumda bulunan bir anahtar deposu sözleşmesi vardır (ana ağ veya belirli bir L2 olabilir). Ardından, kullanıcıların farklı L2'lerde adresleri vardır ve her adres için doğrulama mantığı, anahtar deposu sözleşmesine yönelik bir işaretçidir. Bu adreslerden fon harcamak, fonlar için mevcut (veya daha gerçekçi olarak, çok yeni) bir harcama açık anahtarının kanıtını sağlamayı gerektirecektir.
Bu kanıt çeşitli şekillerde elde edilebilir:
Her işlem için bir kanıta ihtiyaç duymaktan kaçınmak istiyorsak, yalnızca L2 kanıtlarında kurtarma gerektiren daha hafif bir şema uygulayabiliriz. Bir hesaptan yapılan harcama, hesabın içinde saklanan karşılık gelen ortak anahtarıyla birlikte bir harcama anahtarına bağlı olacaktır, ancak kurtarma, geçerli harcama ortak anahtarını anahtar deposuna kopyalamak için bir işlem gerektirecektir. Eski anahtarlarınız güvenli olmasa bile, sanal adresteki fonlar güvendedir: sanal adresi kullanılabilir bir sözleşmeye dönüştürmek için "etkinleştirmek", geçerli harcanan ortak anahtarı çoğaltmak için L2 arası bir kanıt gerektirecektir. Güvenli forumlarda benzer bir mimarinin nasıl çalıştığını açıklayan bir başlık var.
Böyle bir şemaya gizlilik eklemek için yalnızca işaretçileri şifrelememiz ve tüm ispatları ZK-SNARK'ların içinde yapmamız yeterlidir:
Bu senaryolar karmaşıklaşabilir. Olumlu tarafı, aralarında birçok potansiyel sinerji olmasıdır. Örneğin, bir "anahtar deposu sözleşmesi" kavramı, bir önceki bölümde bahsedilen "adres" için de bir çözüm olabilir: Kullanıcıların, anahtarı her güncellediğinde değişmeyen kalıcı bir adrese sahip olmasını istiyorsak, gizliliği koyabilir Meta adresi, şifreleme anahtarı ve diğer bilgiler anahtar deposu sözleşmesine konur ve anahtar deposu sözleşmesinin adresi, kullanıcının "adresi" olarak kullanılır.
Pek çok ikincil altyapının güncellenmesi gerekiyor
ENS kullanmak pahalıdır. Haziran 2023'te eskisi kadar pahalı olmasa da, bir alan adı kaydettirmek için işlem ücreti hala nispeten yüksektir ve bu, bir ENS alan adının maliyetiyle karşılaştırılabilir. Örneğin, zuzalu.eth'e kaydolmanın maliyeti yaklaşık 27 dolardır ve bunun 11 doları işlem ücretidir. Ancak piyasa yeniden yükselişe geçerse, ücretler artacaktır. ETH fiyatı artmasa bile gas ücreti 200 gwei'ye dönerse alan adı kaydı için işlem ücreti 104$'a ulaşacak. Dolayısıyla, insanların ENS'yi fiilen kullanmasını istiyorsak, özellikle de kullanıcıların neredeyse ücretsiz kayıt istediği merkezi olmayan sosyal medya gibi kullanım durumları için (bu platformlar kullanıcılara alt alan adları sağlayabildiğinden ENS alan ücretleri sorun değildir), ENS'nin şu alanlarda kullanılmasına ihtiyacımız var: katman 2.
Neyse ki, ENS ekibi çoktan hızlandı ve ENS, Katman 2'de uygulanıyor! ERC-3668 ("CCIP standardı" olarak da bilinir) ve ENSIP-10, herhangi bir Katman 2'deki ENS alt alanlarını otomatik olarak doğrulamak için bir yol sağlar. CCIP standardı, Katman 2'deki verilerin kanıtlarını doğrulama yöntemini açıklayan bir akıllı sözleşme kurulmasını gerektirir ve böyle bir sözleşmenin kontrolü altına bir alan adı (örneğin, Optimnames için ecc.eth) yerleştirilebilir. CCIP sözleşmesi L1'de ecc.eth'i kontrol ettikten sonra, belirli bir subdomain.ecc.eth'e erişim otomatik olarak o belirli alt alan adının (örn. bir Merkle şubesi) Katman 2 durumunu saklayan bir kanıtı bulur ve doğrular.
**ENS'nin CCIP çabası bir başarı öyküsüdür ve ihtiyacımız olan radikal reformların gerçekten mümkün olduğunun bir işareti olarak görülmelidir. ** Ancak hala yapılması gereken uygulama düzeyinde birçok reform var. İşte bazı örnekler:
Cüzdanların varlıkları ve verileri koruması gerekecek
Şu anda, cüzdanın görevi varlıkları korumaktır. Her şey zincirde saklanır, cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarı değiştirirseniz, önceki özel anahtarı ertesi gün güvenli bir şekilde internette herkese açık olarak gönderebilirsiniz. Ancak, sıfır bilgi dünyasında artık durum böyle değil: cüzdanlar yalnızca kimlik doğrulama bilgilerini korumakla kalmaz, aynı zamanda verilerinizi de tutar.
Böyle bir dünyanın ilk işaretlerini Zuzalu'da ZK-SNARK tabanlı bir kimlik sistemi olan Zupass ile görüyoruz. Kullanıcı, sisteme kimlik doğrulaması yapmak için kullanılan ve "hangi sakini olduğumu açıklamadan Zuzalu'da ikamet ettiğimi kanıtlamak" gibi temel kanıtları oluşturmak için kullanılabilen özel bir anahtara sahiptir. Zupass sistemi ayrıca, en önemlisi damgalar (Zupass'ın POAP versiyonu) olmak üzere başka uygulamalar oluşturmaya başladı.
*Cat Takımının bir üyesi olduğumu onaylayan birçok Zupass pulumdan biri. *
POAP'a göre damgaların temel özelliği, özel olmalarıdır: verileri yerel olarak tutarsınız ve bu bilgiyi birine vermek isterseniz yalnızca ZK'lerine bir damga kanıtlarsınız (veya damgalar üzerinde bazı hesaplamalar yaparsınız). Ancak bu aynı zamanda ek bir riski de beraberinde getirir: Bu bilgiyi kaybederseniz, pullarınızı da kaybedersiniz.
Tabii ki, veri tutma sorunu, tek bir şifreleme anahtarı tutma sorununa indirgenebilir: üçüncü bir taraf (zincirde bile) verilerin şifrelenmiş bir kopyasını tutabilir. Bu, yaptığınız işlemin şifreleme anahtarını değiştirmemesi ve dolayısıyla şifreleme anahtarını tutan sistemle herhangi bir etkileşime gerek olmaması gibi uygun bir avantaja sahiptir. Ancak o zaman bile, şifreleme anahtarını kaybederseniz tüm verilerinizi kaybedersiniz. Ayrıca, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilecek. **
Zupass'ın pratik çözümü, insanları anahtarlarını birden fazla cihazda (dizüstü bilgisayar ve telefon gibi) saklamaya teşvik etmektir, çünkü aynı anda hepsine erişimlerini kaybetme ihtimalleri çok düşüktür. Anahtar deposunu birden fazla koruyucu arasında bölmek için anahtar paylaşımını kullanarak bunu bir adım öteye götürebiliriz.
MPC yoluyla sosyal kurtarma, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut koruyucunun değil, aynı zamanda önceki koruyucuların da kabul edilemez derecede yüksek bir risk olan varlıklarınızı çalmak için işbirliği yapabileceği anlamına gelir. Bir gizlilik ihlali genellikle varlıkların tamamen kaybından daha az riskli olsa da, yüksek gizlilik gereksinimleri olan kullanım durumları için, bu gizlilik gereksinimleriyle ilişkili anahtarların yedeklenmemesiyle daha yüksek bir kayıp riski kabul edilebilir.
Kullanıcıları birden çok kurtarma yolundan oluşan karmaşık bir sistemde mahsur bırakmaktan kaçınmak için, sosyal kurtarmayı destekleyen cüzdanların varlık kurtarma ve şifreleme anahtarı kurtarmanın her iki yönünü de yönetmesi gerekebilir.
Kimliğe geri dön
Bu değişiklikler arasında ortak bir tema, blok zincirinde kimliğin bir temsili olarak bir "adres" kavramının temelden değişmesi gerekeceğidir. ** "Benimle nasıl etkileşime geçileceğine dair talimatlar" artık sadece bir ETH adresi olmayacak; ifade edin. **
Bu yollardan biri, kimliğiniz olarak ENS kullanmaktır: ENS kaydınız, nasıl ödeme yapacağınız ve sizinle nasıl etkileşim kuracağınızla ilgili tüm bilgileri içerebilir, birine bob.eth (veya bob.ecc.eth vb.) gönderirseniz, Sorgulayabilirler. ve etki alanları arasında daha karmaşık yollar ve gizlilik koruması da dahil olmak üzere sizinle etkileşime giren her şey hakkında bilgi edinin.
Ancak, bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
Olası bir çözüm, bu makalenin mimarisinde daha önce bahsedilen anahtar deposu sözleşmesine daha fazla içerik koymaktır. Bir anahtar deposu sözleşmesi sizinle ve sizinle olan etkileşimlerle ilgili çeşitli bilgiler içerebilir (ve CCIP ile bu bilgilerin bir kısmı zincir dışı olabilir), kullanıcılar anahtar deposu sözleşmesini birincil tanımlayıcıları olarak kullanır. Ancak, fiilen aldıkları varlıklar çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri addan bağımsızdır ve sanal ad dostudur: yalnızca belirli sabit başlangıç parametrelerine sahip bir anahtar deposu sözleşmesi tarafından başlatılabilen bir adres oluşturabilirsiniz.
Başka bir çözüm sınıfı, Bitcoin'in ödeme protokolüne benzer şekilde, kullanıcıya yönelik adres kavramını tamamen terk etmeyi içerir. Bir fikir, gönderen ve alıcı arasındaki doğrudan iletişim kanallarına daha fazla güvenmektir; örneğin, gönderen, alıcının kabul etmek istediği herhangi bir isteği göndermek için kullanabileceği bir istek bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir. ödeme.
İlk hareket eden ister gönderen ister alıcı olsun, gerçek zamanlı olarak güncel ödeme bilgileri oluşturmak için cüzdanlara daha fazla güvenmek sürtünmeyi azaltır. Bununla birlikte, kalıcı tanımlayıcılar uygundur (özellikle ENS ile), oysa pratikte gönderici ve alıcı arasındaki doğrudan iletişime güvenmek çok zor bir problemdir, bu nedenle farklı tekniklerin bir kombinasyonu görülebilir.
Tüm bu tasarımlarda, merkezi olmayan ve kullanıcılar için anlaşılır kalmak çok önemlidir. Kullanıcıların mevcut varlıklarının ve onlara yönelik mesajların güncel bir görünümüne kolayca erişebilmelerini sağlamamız gerekiyor. Bu görüşler, özel çözümler yerine açık araçlara dayanmalıdır. Ödeme altyapısının karmaşıklığının anlaşılması ve yeni ortamlara uyarlanması zor olan opak bir "soyutlama kulesi" haline gelmesini önlemek için çok çalışmak gerekecek. Zorluklara rağmen, sıradan kullanıcılar için Ethereum'un ölçeklenebilirliğine, cüzdan güvenliğine ve gizliliğine ulaşmak çok önemlidir. Bu sadece teknik fizibilite ile ilgili değil, ortalama bir kullanıcı için gerçek erişilebilirlik ile ilgili. Bu zorluğun üstesinden gelmemiz gerekiyor.