Geri bildirimleri, incelemeleri ve önerileri için Dan Finlay, Karl Floersch, David Hoffman ve Scroll ve SoulWallet ekiplerine özel teşekkürler.
Ethereum, genç, deneysel bir teknolojiden sıradan kullanıcılara gerçekten açık, küresel ve izinsiz bir deneyim sunabilen olgun bir teknoloji yığınına geçerken, yığının kabaca aynı anda üç büyük teknolojik geçişten geçmesi gerekecek:
L2 genişletme geçişi - herkes toplamalara geçer
Cüzdan güvenlik geçişi - herkes akıllı sözleşme cüzdanlarına geçer
Gizlilik Geçişi - Gizliliği koruyan para transferlerinin kullanılabilir olduğundan ve geliştirme aşamasındaki diğer tüm aygıtların (sosyal iyileşme, kimlik, itibar) gizliliği koruduğundan emin olun
Ekosistem geçiş üçgeni.
İlki olmadan, her işlemin maliyeti 3,75 ABD Doları (başka bir boğa koşusu yaşarsak 82,48 ABD Doları) olduğundan ve kitle pazarını hedefleyen her ürün kaçınılmaz olarak zinciri unutacağından ve her şey için merkezi bir geçici çözüm benimseyeceğinden Ethereum başarısız olur.
İkincisi olmasaydı, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolama konusunda isteksiz oldukları ve herkes merkezi borsalara yöneldiği için Ethereum başarısız olurdu.
Üçüncüsü olmadan Ethereum başarısız olur çünkü tüm işlemler (ve POAP vb.) Verilerinizi büyük ölçüde gizleyen merkezi bir çözüm.
Bu üç geçiş, yukarıda özetlenen nedenlerden dolayı kritiktir. Ancak aynı zamanda zorlayıcıdırlar çünkü bunları uygun şekilde ele almak yakın koordinasyon gerektirir. Geliştirilmesi gereken sadece protokolün işlevselliği değil; bazı durumlarda, Ethereum ile etkileşim şeklimizin temelden değişmesi gerekiyor, bu da uygulamalarda ve cüzdanlarda derin değişiklikler gerektiriyor.
Bu üç geçiş, kullanıcılar ve adresler arasındaki ilişkiyi temelden yeniden şekillendirecek
L2 genişletilmiş bir dünyada, kullanıcılar birçok L2'de var olacaktır. İyimserliğe dayanan bir ExampleDAO üyesi misiniz? O zaman bir İyimserlik hesabınız var! ZkSync'teki stablecoin sisteminde CDP'ye sahip misiniz? O halde ZkSync'te bir hesabınız var! Kakarot'taki bazı uygulamaları denediniz mi? O halde Kakarot'ta bir hesabınız var! Bir kullanıcının yalnızca bir adresi olduğu günler geride kaldı.
*Cesur Cüzdan görüşüme göre dört yerde ETH'm var. Evet, Arbitrum ve Arbitrum Nova farklıdır. Endişelenme, zamanla daha da karışacak! *
Akıllı sözleşme cüzdanları, L1 ve çeşitli L2'lerde aynı adrese sahip olmayı zorlaştırır ve karmaşıklık katar. Bugün, ç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. Ancak akıllı sözleşme cüzdanları ile adres rezerve etmek daha zor hale geliyor. Adresleri ağlarda, özellikle de CREATE2 ve ERC-2470 tekil fabrikalarda eşdeğer bir kod karması yapmaya çalışmak ve yapmak için birçok çalışma yapılmış olsa da, bunun kusursuz bir şekilde çalışmasını sağlamak zordu. Bazı L2'ler ("Tip 4 ZK-EVM" gibi) EVM'ye tam olarak eşdeğer değildir, bunun yerine karma denkliğini önlemek için genellikle Katılık veya ara düzenekler kullanılır. Hash denkliğiniz olsa bile, cüzdanların sahipliğini önemli değişiklikler yoluyla değiştirme olasılığının başka sezgisel olmayan sonuçları vardır.
Gizlilik, kullanıcı başına daha fazla adres gerektirir ve hatta uğraştığımız adres türlerini değiştirebilir. Gizli adres önerisi, kullanıcı başına yalnızca birkaç adres veya L2 başına bir adres yerine yaygın olarak kullanılıyorsa, kullanıcıların işlem başına bir adresi olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların farklı şekilde 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 üç geçişin her biri "bir kullanıcı ~= bir adres" zihinsel modelini farklı şekillerde zayıflatır ve bu etkilerin bazıları geçişin uygulanmasının karmaşıklığına geri döner. İki özel karmaşıklık noktası şunlardır:
Birine ödeme yapmak isteseydiniz, onlara nasıl ödeme yapacağınız konusunda nasıl bilgi edinirdiniz?
Bir kullanıcının zincirlerde farklı yerlerde depolanan çok sayıda varlığı varsa, önemli değişiklikleri ve sosyal iyileşmeyi nasıl gerçekleştirirler?
Üç geçiş ve zincir üstü ödemeler (ve kimlikler)
Scroll'da madeni param var ve kahve için ödeme yapmak istiyorum ("Ben" kelimenin tam anlamıyla bu makalenin yazarı olarak benden bahsediyorsa, o zaman "kahve" elbette "yeşil çay" için bir mecazdır). Bana kahve satıyorsun ama sadece Taiko'da bozuk para alabilirsin. ne yapalım
Temel olarak iki çözüm vardır:
Alıcı cüzdan (bir tüccar veya normal bir birey olabilir), fonları eşzamansız olarak entegre etmek için bazı otomasyonlarla her L2'yi desteklemek için çok çalışır.
Alacaklı, L2'sini ve adresini sağlar ve gönderenin cüzdanı, fonları L2'ler arası bir köprüleme sistemi aracılığıyla otomatik olarak hedef L2'ye yönlendirir.
Elbette, bu çözümler birleştirilebilir: alıcı, kabul etmeye istekli oldukları L2'lerin bir listesini sağlar ve gönderenin cüzdanı, eğer şanslıysa, doğrudan bir göndermeyi veya L2 boyunca köprülenmiş bir yolu içerebilen ödemeyi hesaplar.
Ancak bu, bu üç geçişin sunduğu önemli bir zorluğun yalnızca bir örneğidir: birine ödeme yapmak gibi basit işlemler, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Neyse ki, akıllı sözleşme cüzdanlarına geçiş, adresleme sistemine aşırı yük getirmeyecek, ancak uygulama yığınının diğer bölümlerinde çözülmesi gereken bazı teknik sorunlar var. İşlemle birlikte yalnızca 21000 gas göndermediklerinden emin olmak için cüzdanların güncellenmesi gerekecek ve cüzdanın ödemeyi alan ucunun yalnızca EOA'dan ETH transferini değil, aynı zamanda ETH'yi de izlediğinden emin olmak daha önemli. akıllı sözleşme kodu tarafından gönderilir. Adreslerin değişmez sahipliği varsayımına 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 işleri kolaylaştıracaktır - özellikle, birisi yalnızca ETH olmayan bir ERC20 belirteci alırsa, bu belirteci ERC-4337 paymaster'ları kullanarak gas için ödeme yapmak için kullanabilecektir.
Öte yandan mahremiyet, henüz tam olarak üstesinden gelmediğimiz büyük bir zorluk teşkil ediyor. 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 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 bir sır vaadi ve (ii) gönderenin kripto para birimini göndermesi için bir yol içermesi gerekir. yalnızca alacaklının ödemeyi keşfetmesine yardımcı olmak için alacaklının deşifre edebileceği bilgiler.
Gizli adres protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı, gönderenin harcama anahtarının körlenmiş bir versiyonudur ve diğer kısmı, gönderenin şifreleme anahtarıdır (gerçi minimum uygulamalar her ikisini de ayarlayabilir). anahtarlar aynıdır).
Şifrelemeye ve ZK-SNARK'lara dayalı soyut bir gizli adres şemasının şematik diyagramı.
Buradaki temel ders, mahremiyet dostu bir ekosistemde, kullanıcıların hem genel anahtarları kullanması hem de genel anahtarları şifrelemesi olacaktır ve kullanıcının "ödeme bilgileri" her iki anahtarı da içermelidir. Ödemelerin ötesinde, bu yönde genişlemek için iyi nedenler 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" bunun için 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 bir işlev sağlamalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, özellikle PGP anahtarları olmak üzere Ethereum merkezli olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu hale gelmesine yardımcı olur.
Üç geçiş ve anahtar kurtarma
Her kullanıcının birden çok adresine sahip olduğu bir dünyada kritik değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcının kurtarma sürecini her adreste ayrı ayrı çalıştırmasını sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdanlar, bir kullanıcının tüm adreslerinde aynı anda kurtarma prosedürleri gerçekleştirebilen yazılımlar içerebilir. Ancak, kullanıcı deneyiminin bu kadar basitleştirilmesine rağmen, basit çoklu adres kurtarmayla ilgili üç sorun vardır:
Gaz maliyeti pratik değildir: Bu kendi kendini açıklayıcıdır.
Karşı olgusal adresler: Akıllı sözleşmenin henüz yayınlamadığı adresler (aslında bu, henüz para göndermediğiniz hesaplar anlamına gelir). Bir kullanıcı olarak, sonsuz sayıda karşıolgusal adrese sahip olabilirsiniz: henüz var olmayan L2'ler dahil olmak üzere her L2'de bir veya daha fazla adres ve gizli adres şemasından kaynaklanan başka bir sonsuz karşıolgusal adres kümesi.
Gizlilik: Kullanıcılar kasıtlı olarak birden çok adrese sahipse ve bunları birbirleriyle ilişkilendirmekten kaçınıyorsa, kesinlikle tüm adresleri aynı anda veya yakın bir zamanda geri yükleyerek herkese açık olarak bağlamak istemezler!
Bu sorunları çözmek zordur. Neyse ki, oldukça iyi performans gösteren zarif bir çözüm var: doğrulama mantığını varlık tutmadan ayıran bir mimari.
Her kullanıcının bir yerde bulunan bir anahtar deposu sözleşmesi vardır (ana ağ veya belirli bir L2 olabilir). Kullanıcıların daha sonra farklı L2'lerde adresleri vardır; burada her adres için doğrulama mantığı, anahtar deposu sözleşmesine yönelik bir işaretçidir. Bu adreslerden harcama yapmak, geçerli (veya daha gerçekçi bir ifadeyle en yeni) harcama ortak anahtarını gösteren anahtar deposu sözleşmesine giriş kanıtı gerektirir.
Kanıt çeşitli şekillerde elde edilebilir:
L2'de doğrudan salt okunur L1 erişimi. L2, L1 durumunu doğrudan okumak için değiştirilebilir. Anahtar deposu sözleşmesi L1'deyse, bu, L2 içindeki sözleşmelerin anahtar deposuna "ücretsiz" erişimi olduğu anlamına gelir.
Merkel şubesi. Merkle şubeleri, L1 durumunu L2'ye veya L2 durumunu L1'e doğrulayabilir veya bir L2'nin başka bir L2'ye kısmi durumunu doğrulamak için ikisini birleştirebilirsiniz. Merkle ispatlarının ana zayıflığı, ispat uzunluğu nedeniyle yüksek gaz maliyetidir: bir ispat 5 kB gerektirebilir, ancak bu gelecekte Verkle ağaçları sayesinde < 1 kB'a düşürülecektir.
ZK-SNARK'lar. Çatalların kendileri yerine Merkle çatallarının ZK-SNARK'larını kullanarak veri maliyetlerini azaltabilirsiniz. Bir ZK-SNARK'ın bir bloktaki tüm zincirler arası durum kanıtlarını doğrulaması için zincir dışı toplama teknikleri oluşturulabilir (örneğin, EIP-4337'nin üzerine).
KZG Sözü. L2 veya bunların üzerine inşa edilmiş ş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 verir. ZK-SNARK'lar gibi, çoklu kanıt şemaları, tüm bu kanıtları her blok için tek bir kanıtta birleştirebilir.
Her işlem için kanıt yapmaktan kaçınmak istiyorsak, kurtarmak için yalnızca bir çapraz L2 kanıtı gerektiren daha hafif bir şema uygulayabiliriz. Bir hesaptan yapılan harcama, ilgili ortak anahtarın hesapta saklandığı bir harcama anahtarına bağlı olacaktır, ancak kurtarma, anahtar deposundaki geçerli harcama ortak anahtarını kopyalamak için bir işlem gerektirecektir. Karşı olgusal adreslerdeki fonlar, eski anahtarlarınız güvenli olmasa bile güvenlidir: karşı olgusal bir adresi çalışan bir sözleşmeye dönüştürmek için "etkinleştirmek", geçerli harcama_pubkey'ini çoğaltmak için çapraz L2 kanıtı gerektirir. Güvenli forumlardaki bu başlık, benzer bir mimarinin nasıl çalıştığını açıklar.
Böyle bir şemaya mahremiyet eklemek için, bu işaretçiyi basitçe şifreleriz ve ardından tüm provaları ZK-SNARK'larda yaparız:
Daha fazla çalışmayla (örneğin, bu çalışmayı bir başlangıç noktası olarak kullanarak), ZK-SNARK'ların karmaşıklığının çoğunu ortadan kaldırabilir ve daha basit bir KZG tabanlı şema yapabiliriz.
Bu senaryolar karmaşıklaşabilir. Artı tarafta, aralarında birçok potansiyel sinerji var. Örneğin, "anahtar deposu sözleşmeleri" kavramı, önceki bölümde bahsedilen "adres" sorununu da çözebilir: Kullanıcıların her yeniden anahtarlamasında değişmeyen kalıcı adreslere sahip olmasını istiyorsak, gizli meta Adresleri koyabiliriz. , şifreleme anahtarları 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 yükseltilmesi gerekiyor
ENS kullanmak pahalıdır. Bugün, Haziran 2023'te, işler o kadar da kötü değil: işlem ücretleri yüksek, ancak yine de ENS alan adı ücretleriyle karşılaştırılabilir. zuzalu.eth'e kaydolmak bana yaklaşık 27 dolara mal oldu ve bunun 11 doları işlem ücretiydi. Ancak başka bir boğa piyasamız varsa, ücretler fırlayacak. ETH fiyat artışı olmasa bile, gas ücretlerini 200 gwei'ye geri götürmek, alan adı kayıtları için tx ücretini 104$'a çıkarır. Dolayısıyla, insanların ENS'yi fiilen kullanmasını istiyorsak, özellikle kullanıcıların neredeyse ücretsiz kayıt talep ettiği merkezi olmayan sosyal medya gibi kullanım durumları için (ve bu platformlar kullanıcılarına alt alan adları sağladığından ENS alan ücretleri sorun değildir), çalışması için L2'de ENS'ye ihtiyacımız var. .
Neyse ki, ENS ekibi hızlandı ve L2'de ENS oluyor! ERC-3668 ("CCIP standardı" olarak da bilinir), ENSIP-10 ile birlikte, herhangi bir L2'deki ENS alt alanlarını otomatik olarak doğrulanabilir hale getirmenin bir yolunu sunar. CCIP standardı, L2 verilerinin kanıtlarını doğrulama yöntemini açıklayan bir akıllı sözleşmenin oluşturulmasını ve etki alanlarının (örn. CCIP sözleşmesi L1'de ecc.eth'in kontrolünü ele geçirdiğinde, bazı subdomain.ecc.eth'e erişim otomatik olarak söz konusu alt alan adının gerçekten depolandığı L2'de durum kanıtını (örn. Merkle şubesi) bulmayı ve doğrulamayı içerecektir.
Aslında kanıtları almak, sözleşmede depolanan ve kesinlikle merkezi gibi görünen URL'lerin bir listesini içerir, ancak bence aslında değil: bu bir N-1 güven modeli (geçersiz kanıtlar, CCIP sözleşmesi geri çağırma işlevindeki doğrulama mantığı tarafından yakalanır) , URL'lerden biri geçerli bir kanıt döndürdüğü sürece sorun değil). URL listesi düzinelerce içerebilir.
ENS CCIP çabası bir başarı öyküsüdür ve ihtiyacımız olan radikal reformun aslında mümkün olduğunun bir işareti olarak görülmelidir. Ancak hala yapılması gereken birçok uygulama katmanı reformu var. Birkaç örnek:
Birçok dapp, zincir dışı imzalar sağlamak için kullanıcılara güvenir. Harici Sahiplikli Hesap (EOA) ile bu kolaydır. ERC-1271, akıllı sözleşme cüzdanlarının bunu yapması için standartlaştırılmış bir yol sağlar. Ancak, birçok dapp hala ERC-1271'i desteklememektedir; buna ihtiyaçları olacaktır.
Kullanıcıları ve sözleşmeleri ayırt etmek (örneğin, transferleri önlemek veya telif ücretlerini uygulamak) için "Bu EOA mı?" Genel olarak, burada tamamen teknik çözümler aramamanızı tavsiye ederim; belirli bir kriptografik kontrol transferinin, intifa hakkı devri olup olmadığını anlamak, bazı zincir dışı topluluk odaklı mekanizmalara değinmeden çözülemeyecek zor bir problemdir. Büyük olasılıkla, uygulamalar saptırma engellemeye daha az, Harberger vergileri gibi tekniklere daha fazla güvenmek zorunda kalacak.
Cüzdanların harcama ve şifreleme anahtarlarıyla nasıl etkileşime girdiği iyileştirilmelidir. Şu anda cüzdanlar, uygulamaya özel anahtarlar oluşturmak için genellikle deterministik imzalar kullanır: EOA'nın özel anahtarıyla standart bir nonce (uygulama adının hash'i gibi) imzalamak, özel anahtar olmadan üretilemeyen deterministik bir değer oluşturur, bu nedenle güvenlidir tamamen teknik anlamda. Ancak, bu teknikler cüzdanlar için "opaktır" ve cüzdanların kullanıcı arabirimi düzeyinde güvenlik kontrolleri uygulamasını engeller. Daha olgun ekosistemlerde imzalama, şifreleme ve ilgili işlevlerin cüzdanlar tarafından daha açık bir şekilde ele alınması gerekecektir.
Hafif istemciler (Helios gibi) yalnızca L1'i değil, L2'yi de doğrulamalıdır. Bugün hafif istemciler, L1 başlıklarının geçerliliğini kontrol etmeye (hafif istemci senkronizasyon protokolünü kullanarak) ve L1 durumunun Merkle çatallarını ve L1 başlıklarında kök salmış işlemleri doğrulamaya odaklanıyor. Yarın, L1'de depolanan durum kökünde bulunan L2 durumunun kanıtını da doğrulamaları gerekiyor (daha gelişmiş sürüm aslında L2 ön onayına bakıyor).
Cüzdanların varlıkları ve verileri koruması gerekecek
Bugün, cüzdanlar varlıkları koruma işinde. Her şey zincir üzerindedir ve cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarınızı değiştirirseniz, önceki özel anahtarınızı ertesi gün internette güvenle yayınlayabilirsiniz. Ancak, ZK dünyasında bu artık doğru değil: 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'nun kullandığı ZK-SNARK tabanlı kimlik sistemi Zupass ile gördük. Kullanıcı, sisteme kimlik doğrulaması yapmak için "hangisini açıklamadan Zuzalu'da ikamet ettiğimi kanıtlamak" gibi temel ispatlar yapmak için kullanılabilecek bir özel anahtara sahiptir. Ancak Zupass sistemi, en önemlisi damga (Zupass'ın POAP versiyonu) olmak üzere başka uygulamalar da oluşturmaya başladı.
Cat Takımının gururlu bir üyesi olduğumu doğrulayan birçok Zupass pulumdan biri.
Pulların POAP'a kıyasla sunduğu temel özellik, pulların özel olmasıdır: verileri yerel olarak tutarsınız ve birinin sizin hakkınızda bilgi sahibi olmasını istiyorsanız, sadece bir pulu (veya bir pul üzerindeki bazı hesaplamaları) birisine kanıtlamanız gerekir. Ancak bu risk ekler: Bu bilgiyi kaybederseniz damgayı da kaybedersiniz.
Elbette, veri tutma sorunu tek bir şifreleme anahtarı tutma sorununa indirgenebilir: bazı üçüncü şahıslar (hatta zincir) verilerin şifrelenmiş bir kopyasını tutabilir. Bu, yaptığınız işlemin şifreleme anahtarını değiştirmemesi ve böylece şifreleme anahtarınızı güvende tutan sistemle herhangi bir etkileşime gerek olmaması gibi uygun bir avantaja sahiptir. Ancak o zaman bile, şifreleme anahtarınızı kaybederseniz her şeyinizi kaybedersiniz. Öte yandan, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilir.
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. Bir adım daha ileri gidebilir ve birden çok gözetmen arasında dağıtılan anahtarları saklamak için gizli bir paylaşım kullanabiliriz.
MPC yoluyla bu sosyal iyileşme, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut velilerin değil, aynı zamanda önceki velilerin de varlıklarınızı çalmak için işbirliği yapabileceği anlamına gelir ki bu kabul edilemez derecede yüksek bir risktir. Ancak gizlilik ihlali riski, genellikle toplam varlık kaybı riskinden daha düşüktür ve yüksek gizlilik kullanım durumlarına sahip kişiler, bu gizlilik gerektiren işlemlerle ilişkili anahtarları yedeklemeyerek her zaman daha yüksek bir kayıp riskini kabul edebilir.
Kullanıcıların birden çok kurtarma yoluna sahip Bizans sistemleri tarafından boğulmasını önlemek için, sosyal kurtarmayı destekleyen cüzdanların hem varlık kurtarmayı hem de şifreleme anahtarı kurtarmayı yönetmesi gerekebilir.
Kimliğe geri dön
Bu değişikliklerin ortak noktalarından biri, zincir üzerinde "sizi" temsil etmek için kullandığınız kriptografik tanımlayıcı olan "adres" kavramının temelden değişmesi gerektiğidir. "Benimle nasıl etkileşime geçileceğine ilişkin talimatlar" artık yalnızca bir ETH adresi olmayacak; birden çok L2'deki birden çok adresin, gizli meta adreslerin, şifreleme anahtarlarının ve bir biçimdeki diğer verilerin bir kombinasyonu olmalıdırlar.
Bir yol, ENS'yi kimliğiniz yapmaktır: ENS kaydınız tüm bu bilgileri içerebilir ve birine bob.eth (veya bob.ecc.eth veya...) gönderirseniz, arama yapabilir ve nasıl yapılacağına ilişkin her şeyi görebilir. daha karmaşık alanlar arası ve gizliliği koruyan yöntemler de dahil olmak üzere, ödeme yapar ve sizinle etkileşim kurar.
Ancak bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
Alan adınızla çok fazla şey ilişkilendirir. Alan adınız siz değilsiniz, alan adınız sizin birçok özelliğinizden biridir. Tüm kimlik profilinizi taşımadan ve birçok uygulamada bir sürü kaydı güncellemeden alan adınızı değiştirmek mümkün olmalıdır.
Güvenilmeyen karşı olgusal mısıra sahip olamazsınız. Herhangi bir blok zincirinin önemli bir UX özelliği, henüz zincirle etkileşime girmemiş kişilere jeton gönderme yeteneğidir. Böyle bir işlevsellik olmadan, bir sorun var- 22: zincirle etkileşim, işlem ücretlerinin ödenmesini gerektirir, bu da ... zaten madeni paraya sahip olmayı gerektirir. CREATE2 ile akıllı sözleşme adresleri dahil olmak üzere ETH adresleri bu işlevselliğe sahiptir. ENS isimleri olmayacak, çünkü iki Bob da bob.ecc.eth zincir dışı olduğuna karar verirse, hangisinin ismi alacağını seçmenin bir yolu yok.
Muhtemel bir çözüm, bu makalenin başlarında mimaride bahsedilen anahtar deposu sözleşmesine daha fazla içerik koymaktır. Anahtar deposu sözleşmesi, sizinle ve onunla nasıl etkileşim kurduğunuzla ilgili her türlü bilgiyi içerebilir (CCIP için bu bilgilerin bir kısmı zincir dışı olabilir) ve kullanıcılar anahtar deposu sözleşmesini birincil tanımlayıcıları olarak kullanır. Ancak aldıkları gerçek varlıklar, çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri addan bağımsızdır ve karşı-olgusal dostudur: yalnızca bazı sabit başlangıç parametrelerine sahip bir anahtar deposu sözleşmesi tarafından başlatıldığı kanıtlanabilen bir adres oluşturabilirsiniz.
Başka bir çözüm türü, Bitcoin ödeme protokolüne benzer ve kullanıcı odaklı adres kavramını tamamen terk eder. 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 ödemeyi kabul etme isteğini takip etmek için kullanabileceği bir talep bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir.
Önce göndericinin mi yoksa alıcının mı hareket ettiğine bakılmaksızın, gerçek zamanlı olarak doğrudan güncel ödeme bilgileri oluşturmak için cüzdanlara daha fazla güvenmek anlaşmazlığı azaltır. Bununla birlikte, kalıcı tanımlayıcılar uygundur (özellikle ENS ile), oysa gönderici ve alıcı arasında doğrudan iletişim varsayımı pratikte çok zordur, bu nedenle farklı teknolojilerin bir kombinasyonunu görebiliriz.
Tüm bu tasarımlarda, her şeyi hem ayrık hem de kullanıcıların anlaması kolay hale getirmek en önemlisidir. Kullanıcıların, mevcut varlıklarının ne olduğu ve onlar için hangi haberlerin yayınlandığıyla ilgili en son bilgilere kolayca erişebildiğinden emin olmalıyız. Bu bakış açıları, özel çözümlere değil, açık araçlara dayanmalıdır. Daha karmaşık bir ödeme altyapısının, geliştiricilerin neler olup bittiğini anlamakta zorlandıkları ve onu yeni ortama uyarlamakta zorlandıkları opak bir "soyutlama kulesi" haline gelmesini önlemek için çok çalışmak gerekecek. Zorluklara rağmen, sıradan kullanıcılar için ölçeklenebilirlik, cüzdan güvenliği ve mahremiyet elde etmek, Ethereum'un geleceği için kritik öneme sahiptir. 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 Buterin: Ethereum'un Üç Teknik Geçişi
Orijinal yazar: Ethereum kurucusu Vitalik Buterin
Geri bildirimleri, incelemeleri ve önerileri için Dan Finlay, Karl Floersch, David Hoffman ve Scroll ve SoulWallet ekiplerine özel teşekkürler.
Ethereum, genç, deneysel bir teknolojiden sıradan kullanıcılara gerçekten açık, küresel ve izinsiz bir deneyim sunabilen olgun bir teknoloji yığınına geçerken, yığının kabaca aynı anda üç büyük teknolojik geçişten geçmesi gerekecek:
İlki olmadan, her işlemin maliyeti 3,75 ABD Doları (başka bir boğa koşusu yaşarsak 82,48 ABD Doları) olduğundan ve kitle pazarını hedefleyen her ürün kaçınılmaz olarak zinciri unutacağından ve her şey için merkezi bir geçici çözüm benimseyeceğinden Ethereum başarısız olur.
İkincisi olmasaydı, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolama konusunda isteksiz oldukları ve herkes merkezi borsalara yöneldiği için Ethereum başarısız olurdu.
Üçüncüsü olmadan Ethereum başarısız olur çünkü tüm işlemler (ve POAP vb.) Verilerinizi büyük ölçüde gizleyen merkezi bir çözüm.
Bu üç geçiş, yukarıda özetlenen nedenlerden dolayı kritiktir. Ancak aynı zamanda zorlayıcıdırlar çünkü bunları uygun şekilde ele almak yakın koordinasyon gerektirir. Geliştirilmesi gereken sadece protokolün işlevselliği değil; bazı durumlarda, Ethereum ile etkileşim şeklimizin temelden değişmesi gerekiyor, bu da uygulamalarda ve cüzdanlarda derin değişiklikler gerektiriyor.
Bu üç geçiş, kullanıcılar ve adresler arasındaki ilişkiyi temelden yeniden şekillendirecek
L2 genişletilmiş bir dünyada, kullanıcılar birçok L2'de var olacaktır. İyimserliğe dayanan bir ExampleDAO üyesi misiniz? O zaman bir İyimserlik hesabınız var! ZkSync'teki stablecoin sisteminde CDP'ye sahip misiniz? O halde ZkSync'te bir hesabınız var! Kakarot'taki bazı uygulamaları denediniz mi? O halde Kakarot'ta bir hesabınız var! Bir kullanıcının yalnızca bir adresi olduğu günler geride kaldı.
Akıllı sözleşme cüzdanları, L1 ve çeşitli L2'lerde aynı adrese sahip olmayı zorlaştırır ve karmaşıklık katar. Bugün, ç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. Ancak akıllı sözleşme cüzdanları ile adres rezerve etmek daha zor hale geliyor. Adresleri ağlarda, özellikle de CREATE2 ve ERC-2470 tekil fabrikalarda eşdeğer bir kod karması yapmaya çalışmak ve yapmak için birçok çalışma yapılmış olsa da, bunun kusursuz bir şekilde çalışmasını sağlamak zordu. Bazı L2'ler ("Tip 4 ZK-EVM" gibi) EVM'ye tam olarak eşdeğer değildir, bunun yerine karma denkliğini önlemek için genellikle Katılık veya ara düzenekler kullanılır. Hash denkliğiniz olsa bile, cüzdanların sahipliğini önemli değişiklikler yoluyla değiştirme olasılığının başka sezgisel olmayan sonuçları vardır.
Gizlilik, kullanıcı başına daha fazla adres gerektirir ve hatta uğraştığımız adres türlerini değiştirebilir. Gizli adres önerisi, kullanıcı başına yalnızca birkaç adres veya L2 başına bir adres yerine yaygın olarak kullanılıyorsa, kullanıcıların işlem başına bir adresi olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların farklı şekilde 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 üç geçişin her biri "bir kullanıcı ~= bir adres" zihinsel modelini farklı şekillerde zayıflatır ve bu etkilerin bazıları geçişin uygulanmasının karmaşıklığına geri döner. İki özel karmaşıklık noktası şunlardır:
Birine ödeme yapmak isteseydiniz, onlara nasıl ödeme yapacağınız konusunda nasıl bilgi edinirdiniz?
Bir kullanıcının zincirlerde farklı yerlerde depolanan çok sayıda varlığı varsa, önemli değişiklikleri ve sosyal iyileşmeyi nasıl gerçekleştirirler?
Üç geçiş ve zincir üstü ödemeler (ve kimlikler)
Scroll'da madeni param var ve kahve için ödeme yapmak istiyorum ("Ben" kelimenin tam anlamıyla bu makalenin yazarı olarak benden bahsediyorsa, o zaman "kahve" elbette "yeşil çay" için bir mecazdır). Bana kahve satıyorsun ama sadece Taiko'da bozuk para alabilirsin. ne yapalım
Temel olarak iki çözüm vardır:
Elbette, bu çözümler birleştirilebilir: alıcı, kabul etmeye istekli oldukları L2'lerin bir listesini sağlar ve gönderenin cüzdanı, eğer şanslıysa, doğrudan bir göndermeyi veya L2 boyunca köprülenmiş bir yolu içerebilen ödemeyi hesaplar.
Ancak bu, bu üç geçişin sunduğu önemli bir zorluğun yalnızca bir örneğidir: birine ödeme yapmak gibi basit işlemler, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Neyse ki, akıllı sözleşme cüzdanlarına geçiş, adresleme sistemine aşırı yük getirmeyecek, ancak uygulama yığınının diğer bölümlerinde çözülmesi gereken bazı teknik sorunlar var. İşlemle birlikte yalnızca 21000 gas göndermediklerinden emin olmak için cüzdanların güncellenmesi gerekecek ve cüzdanın ödemeyi alan ucunun yalnızca EOA'dan ETH transferini değil, aynı zamanda ETH'yi de izlediğinden emin olmak daha önemli. akıllı sözleşme kodu tarafından gönderilir. Adreslerin değişmez sahipliği varsayımına 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 işleri kolaylaştıracaktır - özellikle, birisi yalnızca ETH olmayan bir ERC20 belirteci alırsa, bu belirteci ERC-4337 paymaster'ları kullanarak gas için ödeme yapmak için kullanabilecektir.
Öte yandan mahremiyet, henüz tam olarak üstesinden gelmediğimiz büyük bir zorluk teşkil ediyor. 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 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 bir sır vaadi ve (ii) gönderenin kripto para birimini göndermesi için bir yol içermesi gerekir. yalnızca alacaklının ödemeyi keşfetmesine yardımcı olmak için alacaklının deşifre edebileceği bilgiler.
Gizli adres protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı, gönderenin harcama anahtarının körlenmiş bir versiyonudur ve diğer kısmı, gönderenin şifreleme anahtarıdır (gerçi minimum uygulamalar her ikisini de ayarlayabilir). anahtarlar aynıdır).
Buradaki temel ders, mahremiyet dostu bir ekosistemde, kullanıcıların hem genel anahtarları kullanması hem de genel anahtarları şifrelemesi olacaktır ve kullanıcının "ödeme bilgileri" her iki anahtarı da içermelidir. Ödemelerin ötesinde, bu yönde genişlemek için iyi nedenler 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" bunun için 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 bir işlev sağlamalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, özellikle PGP anahtarları olmak üzere Ethereum merkezli olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu hale gelmesine yardımcı olur.
Üç geçiş ve anahtar kurtarma
Her kullanıcının birden çok adresine sahip olduğu bir dünyada kritik değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcının kurtarma sürecini her adreste ayrı ayrı çalıştırmasını sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdanlar, bir kullanıcının tüm adreslerinde aynı anda kurtarma prosedürleri gerçekleştirebilen yazılımlar içerebilir. Ancak, kullanıcı deneyiminin bu kadar basitleştirilmesine rağmen, basit çoklu adres kurtarmayla ilgili üç sorun vardır:
Bu sorunları çözmek zordur. Neyse ki, oldukça iyi performans gösteren zarif bir çözüm var: doğrulama mantığını varlık tutmadan ayıran bir mimari.
Kanıt çeşitli şekillerde elde edilebilir:
Böyle bir şemaya mahremiyet eklemek için, bu işaretçiyi basitçe şifreleriz ve ardından tüm provaları ZK-SNARK'larda yaparız:
Bu senaryolar karmaşıklaşabilir. Artı tarafta, aralarında birçok potansiyel sinerji var. Örneğin, "anahtar deposu sözleşmeleri" kavramı, önceki bölümde bahsedilen "adres" sorununu da çözebilir: Kullanıcıların her yeniden anahtarlamasında değişmeyen kalıcı adreslere sahip olmasını istiyorsak, gizli meta Adresleri koyabiliriz. , şifreleme anahtarları 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 yükseltilmesi gerekiyor
ENS kullanmak pahalıdır. Bugün, Haziran 2023'te, işler o kadar da kötü değil: işlem ücretleri yüksek, ancak yine de ENS alan adı ücretleriyle karşılaştırılabilir. zuzalu.eth'e kaydolmak bana yaklaşık 27 dolara mal oldu ve bunun 11 doları işlem ücretiydi. Ancak başka bir boğa piyasamız varsa, ücretler fırlayacak. ETH fiyat artışı olmasa bile, gas ücretlerini 200 gwei'ye geri götürmek, alan adı kayıtları için tx ücretini 104$'a çıkarır. Dolayısıyla, insanların ENS'yi fiilen kullanmasını istiyorsak, özellikle kullanıcıların neredeyse ücretsiz kayıt talep ettiği merkezi olmayan sosyal medya gibi kullanım durumları için (ve bu platformlar kullanıcılarına alt alan adları sağladığından ENS alan ücretleri sorun değildir), çalışması için L2'de ENS'ye ihtiyacımız var. .
Neyse ki, ENS ekibi hızlandı ve L2'de ENS oluyor! ERC-3668 ("CCIP standardı" olarak da bilinir), ENSIP-10 ile birlikte, herhangi bir L2'deki ENS alt alanlarını otomatik olarak doğrulanabilir hale getirmenin bir yolunu sunar. CCIP standardı, L2 verilerinin kanıtlarını doğrulama yöntemini açıklayan bir akıllı sözleşmenin oluşturulmasını ve etki alanlarının (örn. CCIP sözleşmesi L1'de ecc.eth'in kontrolünü ele geçirdiğinde, bazı subdomain.ecc.eth'e erişim otomatik olarak söz konusu alt alan adının gerçekten depolandığı L2'de durum kanıtını (örn. Merkle şubesi) bulmayı ve doğrulamayı içerecektir.
ENS CCIP çabası bir başarı öyküsüdür ve ihtiyacımız olan radikal reformun aslında mümkün olduğunun bir işareti olarak görülmelidir. Ancak hala yapılması gereken birçok uygulama katmanı reformu var. Birkaç örnek:
Cüzdanların varlıkları ve verileri koruması gerekecek
Bugün, cüzdanlar varlıkları koruma işinde. Her şey zincir üzerindedir ve cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarınızı değiştirirseniz, önceki özel anahtarınızı ertesi gün internette güvenle yayınlayabilirsiniz. Ancak, ZK dünyasında bu artık doğru değil: 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'nun kullandığı ZK-SNARK tabanlı kimlik sistemi Zupass ile gördük. Kullanıcı, sisteme kimlik doğrulaması yapmak için "hangisini açıklamadan Zuzalu'da ikamet ettiğimi kanıtlamak" gibi temel ispatlar yapmak için kullanılabilecek bir özel anahtara sahiptir. Ancak Zupass sistemi, en önemlisi damga (Zupass'ın POAP versiyonu) olmak üzere başka uygulamalar da oluşturmaya başladı.
Pulların POAP'a kıyasla sunduğu temel özellik, pulların özel olmasıdır: verileri yerel olarak tutarsınız ve birinin sizin hakkınızda bilgi sahibi olmasını istiyorsanız, sadece bir pulu (veya bir pul üzerindeki bazı hesaplamaları) birisine kanıtlamanız gerekir. Ancak bu risk ekler: Bu bilgiyi kaybederseniz damgayı da kaybedersiniz.
Elbette, veri tutma sorunu tek bir şifreleme anahtarı tutma sorununa indirgenebilir: bazı üçüncü şahıslar (hatta zincir) verilerin şifrelenmiş bir kopyasını tutabilir. Bu, yaptığınız işlemin şifreleme anahtarını değiştirmemesi ve böylece şifreleme anahtarınızı güvende tutan sistemle herhangi bir etkileşime gerek olmaması gibi uygun bir avantaja sahiptir. Ancak o zaman bile, şifreleme anahtarınızı kaybederseniz her şeyinizi kaybedersiniz. Öte yandan, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilir.
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. Bir adım daha ileri gidebilir ve birden çok gözetmen arasında dağıtılan anahtarları saklamak için gizli bir paylaşım kullanabiliriz.
MPC yoluyla bu sosyal iyileşme, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut velilerin değil, aynı zamanda önceki velilerin de varlıklarınızı çalmak için işbirliği yapabileceği anlamına gelir ki bu kabul edilemez derecede yüksek bir risktir. Ancak gizlilik ihlali riski, genellikle toplam varlık kaybı riskinden daha düşüktür ve yüksek gizlilik kullanım durumlarına sahip kişiler, bu gizlilik gerektiren işlemlerle ilişkili anahtarları yedeklemeyerek her zaman daha yüksek bir kayıp riskini kabul edebilir.
Kullanıcıların birden çok kurtarma yoluna sahip Bizans sistemleri tarafından boğulmasını önlemek için, sosyal kurtarmayı destekleyen cüzdanların hem varlık kurtarmayı hem de şifreleme anahtarı kurtarmayı yönetmesi gerekebilir.
Kimliğe geri dön
Bu değişikliklerin ortak noktalarından biri, zincir üzerinde "sizi" temsil etmek için kullandığınız kriptografik tanımlayıcı olan "adres" kavramının temelden değişmesi gerektiğidir. "Benimle nasıl etkileşime geçileceğine ilişkin talimatlar" artık yalnızca bir ETH adresi olmayacak; birden çok L2'deki birden çok adresin, gizli meta adreslerin, şifreleme anahtarlarının ve bir biçimdeki diğer verilerin bir kombinasyonu olmalıdırlar.
Bir yol, ENS'yi kimliğiniz yapmaktır: ENS kaydınız tüm bu bilgileri içerebilir ve birine bob.eth (veya bob.ecc.eth veya...) gönderirseniz, arama yapabilir ve nasıl yapılacağına ilişkin her şeyi görebilir. daha karmaşık alanlar arası ve gizliliği koruyan yöntemler de dahil olmak üzere, ödeme yapar ve sizinle etkileşim kurar.
Ancak bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
Muhtemel bir çözüm, bu makalenin başlarında mimaride bahsedilen anahtar deposu sözleşmesine daha fazla içerik koymaktır. Anahtar deposu sözleşmesi, sizinle ve onunla nasıl etkileşim kurduğunuzla ilgili her türlü bilgiyi içerebilir (CCIP için bu bilgilerin bir kısmı zincir dışı olabilir) ve kullanıcılar anahtar deposu sözleşmesini birincil tanımlayıcıları olarak kullanır. Ancak aldıkları gerçek varlıklar, çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri addan bağımsızdır ve karşı-olgusal dostudur: yalnızca bazı sabit başlangıç parametrelerine sahip bir anahtar deposu sözleşmesi tarafından başlatıldığı kanıtlanabilen bir adres oluşturabilirsiniz.
Başka bir çözüm türü, Bitcoin ödeme protokolüne benzer ve kullanıcı odaklı adres kavramını tamamen terk eder. 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 ödemeyi kabul etme isteğini takip etmek için kullanabileceği bir talep bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir.
Tüm bu tasarımlarda, her şeyi hem ayrık hem de kullanıcıların anlaması kolay hale getirmek en önemlisidir. Kullanıcıların, mevcut varlıklarının ne olduğu ve onlar için hangi haberlerin yayınlandığıyla ilgili en son bilgilere kolayca erişebildiğinden emin olmalıyız. Bu bakış açıları, özel çözümlere değil, açık araçlara dayanmalıdır. Daha karmaşık bir ödeme altyapısının, geliştiricilerin neler olup bittiğini anlamakta zorlandıkları ve onu yeni ortama uyarlamakta zorlandıkları opak bir "soyutlama kulesi" haline gelmesini önlemek için çok çalışmak gerekecek. Zorluklara rağmen, sıradan kullanıcılar için ölçeklenebilirlik, cüzdan güvenliği ve mahremiyet elde etmek, Ethereum'un geleceği için kritik öneme sahiptir. 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.