Ethereum, genç bir deneysel teknolojiden sıradan kullanıcılara gerçekten açık, küresel ve izinsiz bir deneyim getirebilen olgun bir teknoloji yığınına dönüştüğünde, yığının üç büyük teknolojik dönüşümden geçmesi gerekir, kabaca Eşzamanlı olarak:
Wallet Security Shift - Tümü Akıllı Sözleşme Cüzdanlarına Geçiyor
Privacy Shift - Gizliliği koruyan para transferlerini sağlayın ve geliştirilmekte olan diğer tüm araçların (sosyal kurtarma, kimlik, itibar) gizliliği koruduğundan emin olun
Bu, ekosistem dönüşümünün üçgenidir. 3'ten sadece 3'ünü seçebilirsiniz.
İlki olmadan, Ethereum başarısız olur çünkü her işlemin maliyeti 3,75 ABD Doları olur (başka bir boğa koşusu yaşarsak 82,48 ABD Doları) ve her kitlesel pazar ürünü sonunda zinciri unutur ve her şey için merkezi bir çözüm alır.
İkincisi olmadan, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolama konusunda isteksiz olacağından ve hepsi merkezi borsalara taşınacağından Ethereum başarısız olur.
Üçüncüsü olmadan, Ethereum başarısız olur, çünkü tüm işlemler (ve POAP'ler, vb.) herkesin görmesi için halka açık olur, bu da birçok kullanıcı için mahremiyetten fahiş bir fedakarlık olur ve herkes en azından bazı gizli verilere sahip olmak için harekete geçer. çözüm.
Yukarıda belirtilen nedenlerden dolayı, bu üç geçiş kritiktir. Ancak bunları çözmek için gereken yoğun koordinasyon nedeniyle de zorlayıcıdırlar. Sadece protokolün işlevselliğinin iyileştirilmesi gerekmiyor, Ethereum ile etkileşim biçimimizde, uygulamalarda ve cüzdanlarda derin değişiklikler gerektiren oldukça temel değişikliklerin yapılması gereken durumlar var.
Bu üç değişiklik, kullanıcılar ve adresler arasındaki ilişkide devrim yaratacak
L2 genişletilmiş bir dünyada, kullanıcılar birçok L2'de var olacaktır. İyimserlik üzerine olan ExampleDAO'ya üye misiniz? O zaman Optimism'de bir hesabınız var! ZkSync'in stablecoin sisteminde CDP'ye sahip misiniz? O halde ZkSync'te bir hesabınız var! 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üşüme göre dört yerde ETH'm var. Evet, Arbitrum ve Arbitrum Nova farklıdır. Endişelenme, bu zamanla daha da karmaşıklaşacak!
Akıllı sözleşme cüzdanları daha fazla karmaşıklık ekleyerek L1 ve çeşitli L2'lerde aynı adrese sahip olmayı zorlaştırır. Bugün, çoğu kullanıcı, adresleri aslında imzayı doğrulamak için kullanılan genel anahtarın karması 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 bir adresi korumak daha zor hale gelir. Başta CREATE2 ve ERC-2470 tekil fabrikalar olmak üzere ağ genelinde adresleri bir kod karması eşdeğeri yapmaya çalışmak için birçok çalışma yapılmış olsa da, bunu mükemmel bir şekilde yapmak çok zordu. Bazı L2'ler ("tip 4 ZK-EVM'ler" gibi), EVM'lere tam olarak eşdeğer değildir, genellikle bunun yerine Sağlamlık veya bir ara düzenek kullanarak karma denkliğini önler. 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 ele aldığımız adres türlerini değiştirebilir. Kullanıcı başına yalnızca birkaç adres veya L2 başına bir adres yerine özel adres önerisi yaygın olarak kullanılıyorsa, işlem başına bir adres olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların nasıl farklı şekilde saklandığını 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 adres sistemine güvenmesi gerekir.
Gördüğümüz gibi, üç vardiya, "tek kullanıcı ~= tek adres" zihinsel modelini farklı şekillerde zayıflattı ve bu etkilerin bazıları, vardiyaları uygulamanın karmaşıklığını geri besledi. İki özel komplikasyon şunlardır:
Birine ödeme yapmak istiyorsanız, onlara ödeme yapma bilgilerini nasıl edinirsiniz?
Bir kullanıcı birçok varlığı farklı zincirlerde farklı yerlerde depolarsa, anahtar değiştirme ve sosyal kurtarmayı nasıl gerçekleştirir?
Üç geçiş, zincir üstü ödemelerle (ve kimlikle) ilgilidir
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 Taiko'dan sadece bozuk para alacaksın. ben ne yaparım?
Temel olarak iki çözüm vardır:
Alıcı cüzdan (bir tüccar veya sadece normal bir birey olabilir), fonları eşzamansız olarak entegre etmek için bazı otomatik işlevlerle her L2'yi desteklemeye çalışır.
Alıcı, L2'sini ve adresini sağlar ve gönderenin cüzdanı, fonları otomatik olarak bir çeşit L2 arası köprüleme sistemi aracılığıyla hedef L2'ye yönlendirir.
Elbette bu çözümler birleştirilebilir: alıcı, kabul etmeye istekli olduğu L2 listesini sağlar ve gönderenin cüzdanı, doğrudan (şansları varsa) veya L2 boyunca köprülü bir yol aracılığıyla göndermeyi içerebilen ödemeyi hesaplar.
Ancak bu, üç vardiyanın getirdiği temel zorluğun yalnızca bir örneği: birine ödeme yapmak kadar basit bir şey, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Akıllı sözleşme cüzdanlarına geçiş, neyse ki adres sistemine fazla yük getirmedi, ancak uygulama yığınının diğer bölümlerinde ele alınması gereken bazı teknik sorunlar var. Cüzdanların, işlemlerde yalnızca 21000 gas göndermediğinden emin olmak için değil, daha da önemlisi, cüzdanın ödeme alan tarafının yalnızca EOA'lardan ETH transferlerini değil, akıllı sözleşme koduyla gönderilen ETH'yi de izlemesini sağlamak için güncellenmesi gerekiyor. 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ı ayrıca bazı şeyleri kolaylaştıracaktır - özellikle, birisi yalnızca ETH olmayan ERC20 belirteçlerini kabul ederse, bu belirteçle benzin için ödeme yapmak için bir ERC-4337 ödemesini kullanabilecektir.
Öte yandan, mahremiyet, henüz tam olarak çözemediğimiz büyük sorunları yeniden ortaya çıkarıyor. Orijinal Tornado Cash, dahili transferleri desteklemediği için bu sorunları ortaya çıkarmadı: kullanıcılar yalnızca sisteme para yatırabilir ve para çekebilirdi. Dahili aktarımlar gerçekleştirebildiğinizde, kullanıcıların gizlilik sisteminin dahili adres şemasını kullanması gerekir. 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 sözü içermesi ve (ii) gönderenin yalnızca şifreli bir mesaj göndermesi gerekir. alıcı, alıcıların ödemeleri keşfetmesine yardımcı olmanın yolunun şifresini çözebilir.
Gizlilik adresi protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı, gönderenin harcama anahtarının gizli bir versiyonudur ve diğer kısım, gönderenin şifreleme anahtarıdır (minimum uygulamalar olmasına rağmen). Bunu ayarlayabilir Her iki tuş da aynıdır).
Buradaki temel ders, gizlilik odaklı 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 gerektiğidir. Ödemenin yanı sıra, bu yönde genişlemek için başka iyi nedenler de var. Örneğin, Ethereum'da şifrelenmiş e-posta istiyorsak, kullanıcıların herkese açık bir şekilde bir tür şifreleme anahtarı sağlaması gerekir. "EOA dünyasında", bunu başarmak için hesap anahtarlarını yeniden kullanabiliriz, ancak güvenli akıllı sözleşme cüzdanları dünyasında, muhtemelen bunu başarmak için daha belirgin işlevselliğe sahip olmalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, Ethereum merkezli olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu hale getirilmesine yardımcı olacaktır, en belirgin örnek PGP anahtarlarıdır.
Üç dönüşüm ve anahtar kurtarma
Bir kullanıcının birden çok adresine sahip olabileceği bir dünyada, temel değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcının her adres için ayrı ayrı kurtarma yordamları gerçekleştirmesini sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdanlar, tüm kullanıcıların adreslerinde aynı anda kurtarma prosedürlerini gerçekleştirmek için yazılım içerebilir. Bununla birlikte, bu tür bir UX basitleştirmesinde bile, saf çoklu adres kurtarmada üç sorun vardır:
Gerçekçi olmayan gaz faturaları: Bu, kendisi için konuşuyor.
Karşı Olgusal Adres: Akıllı sözleşmesi henüz yayınlanmamış bir adres (aslında bu, henüz para göndermediğiniz bir hesap anlamına gelir). Bir kullanıcı olarak, potansiyel olarak sonsuz sayıda karşıolgusal adrese sahipsiniz: henüz var olmayan L2'ler dahil olmak üzere her L2'de bir veya daha fazla ve steganografik adres şemasından türetilen tamamen farklı bir sonsuz karşıolgusal adres kümesi.
Gizlilik: Bir kullanıcının kasıtlı olarak birbirine bağlamamak için birçok adresi varsa, kesinlikle aynı anda veya yaklaşık olarak geri yükleyerek hepsini herkese açık bir şekilde bağlamak istemezler!
Bu sorunları çözmek zordur. Neyse ki, oldukça iyi performans gösteren oldukça zarif bir çözüm var: doğrulama mantığını varlık tutmadan ayıran bir mimari.
Her kullanıcının bir konumda bulunan bir anahtar deposu sözleşmesi vardır (ana ağ veya belirli bir L2 olabilir). Kullanıcılar daha sonra farklı L2'lerde adreslere sahiptir; burada her adres için doğrulama mantığı, anahtar deposu sözleşmesine yönelik bir işaretçidir. Bu adreslerden yapılan harcamalar, geçerli (veya daha gerçekçi bir ifadeyle, en yeni) harcama genel anahtarını gösteren anahtar deposu sözleşmesinde bir kanıt gerektirecektir.
Kanıt çeşitli şekillerde elde edilebilir:
Doğrudan L2'de salt okunur L1 erişimi. L2, onlara L1'in durumunu doğrudan okumaları için bir yol verecek şekilde 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.
Merkel şubesi. Merkle şubeleri, L1 durumlarını L2'ye veya L2 durumlarını L1'e kanıtlayabilir veya bir L2 durumunun parçalarını başka bir L2'ye kanıtlamak 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'nin altına düşecektir.
ZK-SNARK'lar. Şubelerin kendileri yerine Merkle şubelerinin ZK-SNARK'larını kullanarak veri maliyetlerini düşürebilirsiniz. Zincir dışı toplama teknikleri (örn. EIP-4337'ye dayalı), tek bir ZK-SNARK'ın tüm zincirler arası durum kanıtlarını tek bir blokta doğrulaması için oluşturulabilir.
KZG Taahhüdü. L2 veya bunun üzerine inşa edilmiş şemalar, bu sistem içindeki durum kanıtlarının yalnızca 48 bayt uzunluğunda olmasına izin veren sıralı bir adresleme sistemi sunabilir. ZK-SNARK'lar gibi, çoklu kanıt şeması, 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, daha hafif bir çözüm uygulayabiliriz, yalnızca kurtarma sırasında çapraz L2 kanıtı yapmamız gerekir. Bir hesaptan yapılan harcama, ilgili ortak anahtarın hesapta saklandığı bir harcama anahtarına bağlı olacaktır, ancak kurtarma, anahtar deposundaki mevcut harcama ortak anahtarını kopyalayan bir işlem gerektirecektir. Karşı-olgusal bir adresteki fonlar, eski anahtarınız şu olmasa bile güvendedir: bir karşı-olgusal adresi "etkinleştirmek", onu çalışan bir sözleşmeye dönüştürmek, mevcut harcama ortak anahtarını kopyalayan bir L2 arası kanıt yapmayı gerektirecektir. Güvenli forumlardaki bu başlık, benzer bir mimarinin nasıl çalışabileceğini açıklar.
Böyle bir şemaya gizlilik eklemek için, sadece işaretçiyi şifrelememiz ve ardından ZK-SNARK'lardaki tüm ispatları yapmamız gerekiyor:
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. Ancak, bu programlar arasında birçok potansiyel sinerji vardır. Örneğin, bir "anahtar deposu sözleşmesi" kavramı, önceki bölümde bahsedilen "adres" sorununa da bir çözüm olabilir: Kullanıcıların, anahtarlarını güncellediklerinde değişmeyen kalıcı adreslere sahip olmalarını istiyorsak, biz gizli meta adresleri, şifreleme anahtarları ve diğer bilgileri bir anahtar deposu sözleşmesine koymak ve anahtar deposu sözleşmesinin adresini kullanıcının "adresi" olarak kullanmak mümkündür.
Pek çok ikincil altyapının güncellenmesi gerekiyor
ENS kullanmak pahalıdır. Bugün, Haziran 2023, işler o kadar da kötü değil: işlem ücretleri yüksek olsa da ENS alan ücretleriyle karşılaştırılabilir. zuzalu.eth'e kaydolmak bana yaklaşık 27 dolara mal oldu ve bunun 11 doları işlem ücreti. Ancak başka bir boğa piyasamız varsa, ücretler fırlayacak. ETH fiyat artışı olmasa bile, gas ücretinin 200 gwei'ye geri döndürülmesi, alan adı kaydı için işlem ücretini 104$'a çıkarır. Bu nedenle, insanların ENS'yi gerçekten kullanmasını istiyorsak, özellikle kullanıcıların neredeyse ücretsiz kayıt istediği merkezi olmayan sosyal medya gibi kullanım durumları için (bu platformlar, kullanıcıları için alt alanlar sağladığından ENS alan ücretleri sorun değildir), L2'de ENS Çalışmalarına ihtiyacımız var. .
Neyse ki, ENS ekibi zaten hareket halinde ve L2'deki ENS gerçekten oluyor! ERC-3668 ("CCIP standardı" olarak da bilinir), ENSIP-10 ile birlikte, herhangi bir L2'de ENS alt alanlarını otomatik olarak doğrulamak için bir yöntem sağlar. CCIP standardı, L2 verilerinin kanıtlarını doğrulamak için bir yöntemi açıklayan bir akıllı sözleşme kurulmasını gerektirir ve alan adları (örneğin, Optimnames için ecc.eth) böyle bir sözleşmenin kontrolü altına alınabilir. CCIP sözleşmesi L1'de ecc.eth'i kontrol ettikten sonra, bazı subdomain.ecc.eth'e erişmek, otomatik olarak söz konusu alt etki alanını fiilen saklayan kanıtın (örn. Merkle şubesi) L2 durumunu bulmayı ve doğrulamayı içerecektir.
Aslında kanıt elde etmek, sözleşmede saklanan bir dizi URL'ye erişmeyi içerir; bu, kuşkusuz merkezileştirme gibi hissettirir, ancak bunun aslında olmadığını iddia etsem de: bu bir 1-of-N güven modelidir (geçersiz kanıtlar CCIP tarafından engellenir. sözleşmenin geri arama işlevindeki mantık, geçerli bir kanıt döndüren bir URL olduğu sürece sorun olmadığını yakalar). Bu URL listesi düzinelerce URL içerebilir.
ENS CCIP'in çalışması bir başarı öyküsüdür ve ihtiyacımız olan radikal reformun mümkün olduğunun bir işareti olarak görülmelidir. Ancak uygulama düzeyinde daha fazla reforma ihtiyaç var. Bazı örnekler şunları içerir:
Birçok dapp, zincir dışı imzalar sağlamak için kullanıcılara güvenir. Harici Sahiplikli Hesaplar (EOA'lar) için 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 desteklemiyor; desteklemeleri gerekiyor.
Kullanıcılar ve sözleşmeler arasında ayrım yapmak için (örneğin, aktarımları önlemek veya telif ücretlerini uygulamak için) "Bu EOA mı?" Genel olarak, tamamen teknik bir çözüm bulmaya çalışmamanızı tavsiye ederim; belirli bir kriptografik kontrol transferinin faydalı bir menfaat transferi olup olmadığını anlama sorusu, zincir dışı bir topluluğa başvurmadan çözülemeyecek zor bir sorudur. güdümlü mekanizmalar Sonraki çöz. Büyük olasılıkla, uygulamaların transferleri engellemeye daha az, Harberger vergisi gibi tekniklere daha fazla dayanması gerekecek.
Cüzdanların harcama ve şifreleme anahtarlarıyla nasıl etkileşime girdiğinin iyileştirilmesi gerekecek. Ş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 (örneğin, uygulama adının bir karması) imzalanır ve özel anahtar olmadan üretilemeyen bir nonce oluşturulur. , bu nedenle 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ı gerekir.
Hafif istemciler (örn. Helios), yalnızca L1'i değil, L2'yi doğrulamak zorunda kalacaktır. Bugün hafif istemciler, L1 başlığının geçerliliğini kontrol etmeye (hafif istemci senkronizasyon protokolünü kullanarak) ve L1 başlığından kaynaklanan işlemlerin L1 durumunu ve Merkle çatallarını doğrulamaya odaklanmaktadır. Yarın, L1'de saklanan durum kökünden kaynaklanan L2 durumunun kanıtını da doğrulamaları gerekiyor (bu daha gelişmiş sürüm aslında L2'nin ön onayına bakıyor).
Cüzdanların varlıkları ve verileri koruması gerekir
Şimdi, cüzdanın işi varlıkları korumaktır. Her şey zincir üzerindedir ve cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarları değiştirirseniz, önceki özel anahtarınızı ertesi gün internette güvenle yayınlayabilirsiniz. Ancak, sıfır bilgi kanıtlarının olduğu bir dünyada durum artık böyle değil: cüzdanlar yalnızca kimlik doğrulama bilgilerini korumakla kalmıyor, verilerinizi de koruyor.
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ın, "Zuzalu'da ikamet ettiğimi kanıtlayın, ancak hangisi olduğunu açıklamayın" gibi temel kanıtları yapmak için kullanılabilecek, sistemin kimliğini doğrulamak için kullandıkları bir özel anahtarı vardır. Bununla birlikte, Zupass sistemi, üzerine inşa edilmiş başka uygulamalara da sahip olmaya başladı, en önemlisi Stamps (Zupass'ın POAP versiyonu).
Team Cat'in gururlu bir üyesi olduğumu kanıtlayan birçok Zupass pulumdan biri.
Damgaların POAP'ler üzerinden sunduğu temel özellik, damgaların özel olmasıdır: verileri yerel olarak tutarsınız ve damgayı (veya üzerindeki bazı hesaplamaları) yalnızca sizin hakkınızda bu bilgilere sahip olmalarını istiyorsanız kanıtlarsınız. Ancak bu, riski artırır: Bu bilgiyi kaybederseniz, damganızı kaybedersiniz.
Elbette, verileri tutma sorunu, bir kriptografik anahtarı tutma sorununa indirgenir: üçüncü bir taraf (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. Tersine, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilir.
Zupass'ın fiili çözümü, insanları anahtarlarını birden fazla cihazda (örneğin, dizüstü bilgisayar ve telefon) saklamaya teşvik etmektir, çünkü aynı anda hepsini kaybetme şansları zayıftır. Bir adım daha ileri gidebilir ve anahtarı depolamak için gizli bir paylaşım kullanabilir, anahtarı birden fazla gözetmen arasında paylaştırabiliriz.
MPC yoluyla bu sosyal iyileşme, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut vasilerin değil, aynı zamanda önceki vasilerin de varlıklarınızı çalmak için anlaşabileceği anlamına gelir ki bu kabul edilemez bir yüksek risktir. Bununla birlikte, mahremiyet ihlali genellikle varlıkların tamamen kaybolmasından daha az risk taşır ve birisi mahremiyeti yüksek düzeyde koruyan bir kullanım senaryosuna ihtiyaç duyarsa, gizlilik gerektiren ilişkili anahtarları yedeklemeyerek daha yüksek bir kayıp riskini kabul edebilir. eylemlerin korunması.
Çoklu kurtarma yollarından oluşan karmaşık bir sistemle kullanıcıları bunaltmaktan kaçınmak için, sosyal kurtarmayı destekleyen cüzdanların hem varlık kurtarmayı hem de şifreleme anahtarı kurtarmayı yönetmesi gerekebilir.
Kimlik sorusuna geri dön
Bu değişikliklerin ortak bir teması, zincir üzerinde "sizi" temsil eden bir kriptografik tanımlayıcı olarak kullandığınız bir "adres" kavramının kökten değişmesi gerektiğidir. "Benimle nasıl etkileşime geçileceğine dair talimatlar" artık yalnızca bir ETH adresi değil; birden çok L2'deki birden çok adresin, gizli meta adreslerin, şifreleme anahtarlarının ve bir biçimde diğer verilerin bir kombinasyonunu içermelidirler.
Bunu yapmanın bir yolu, 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, o kişi bunu öğrenebilir ve öğrenebilir. daha karmaşık kesişen ve gizliliği koruyan yollar da dahil olmak üzere, ödeme yapan ve sizinle etkileşime giren her şey.
Ancak, bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
Adına çok fazla şey bağlar. Adınız siz değilsiniz, adınız birçok özelliğinizden sadece biri. Tüm kimlik profilinizi taşımadan ve birçok uygulamada bir grup kaydı güncellemeden adınızı değiştirebilmelisiniz.
Güvenilmeyen karşı olgusal isimlere 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 tavuk-yumurta sorunu vardır: zincirle etkileşim, işlem ücretlerinin ödenmesini gerektirir ve ücretlerin ödenmesi, zaten madeni paraya sahip olmayı gerektirir. CREATE2 ile akıllı sözleşme adresleri dahil olmak üzere ETH adresleri bu özelliğe sahiptir. ENS adı öyle değil çünkü iki Bob da kendilerinin bob.ecc.eth zincir dışı olduğuna karar verirse, adı hangisinin alacağını seçmenin bir yolu yok.
Muhtemel bir çözüm, bu yazının başlarında mimaride bahsedilen anahtar deposu sözleşmesine daha fazla öğe koymaktır. Anahtar deposu sözleşmesi, sizinle ve onunla nasıl etkileşim kurduğunuzla ilgili (bazıları zincir dışı olabilen CCIP aracılığıyla) çeşitli bilgiler içerebilir ve kullanıcılar, anahtar deposu sözleşmelerini birincil tanımlayıcı olarak kullanabilir. Ancak aldıkları gerçek varlıklar, çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri adlara bağlı değildir, karşı olgusaldır: yalnızca bazı sabit başlangıç parametreleriyle bir anahtar deposu sözleşmesi tarafından başlatılabilen bir adres oluşturabilirsiniz.
Başka bir çözüm kategorisi, ruhen Bitcoin ödeme protokolüne benzeyen kullanıcı odaklı adresler kavramını terk etmekle ilgilidir. 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 ödemeleri istediği şekilde kullanabileceği bir talep bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir.
İlk hareket eden ister gönderen ister alıcı olsun, gerçek zamanlı olarak doğrudan 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) ve pratikte gönderici ile alıcı arasında doğrudan iletişim varsayımı çok zor bir problemdir, bu nedenle farklı teknolojilerin bir kombinasyonuna bakabiliriz.
Tüm bu tasarımlarda, her şeyi merkezi olmayan ve kullanıcılar için anlaşılır kılmak çok önemlidir. Kullanıcıların mevcut varlıklarının en güncel görünümüne ve kendilerine yönelik yayınlanmış bilgilere kolayca ulaşabilmesini sağlamamız gerekiyor. Bu görüşler, özel çözümler yerine açık araçlara dayanmalıdır. Daha karmaşık bir ödeme altyapısının, geliştiricilerin neler olup bittiğini anlaması ve onu yeni ortama uyarlaması için 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.
Geri bildirimleri, incelemeleri ve önerileri için Dan Finlay, Karl Floersch, David Hoffman ve Scroll ve SoulWallet ekiplerine özel teşekkürler.
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'un gerekli dönüşümü - L2 ölçeklendirme, cüzdan güvenliği ve gizliliği
Ethereum, genç bir deneysel teknolojiden sıradan kullanıcılara gerçekten açık, küresel ve izinsiz bir deneyim getirebilen olgun bir teknoloji yığınına dönüştüğünde, yığının üç büyük teknolojik dönüşümden geçmesi gerekir, kabaca Eşzamanlı olarak:
L2 ölçeklendirme kayması - tümü toplamalara taşındı
Wallet Security Shift - Tümü Akıllı Sözleşme Cüzdanlarına Geçiyor
Privacy Shift - Gizliliği koruyan para transferlerini sağlayın ve geliştirilmekte olan diğer tüm araçların (sosyal kurtarma, kimlik, itibar) gizliliği koruduğundan emin olun
Bu, ekosistem dönüşümünün üçgenidir. 3'ten sadece 3'ünü seçebilirsiniz.
İlki olmadan, Ethereum başarısız olur çünkü her işlemin maliyeti 3,75 ABD Doları olur (başka bir boğa koşusu yaşarsak 82,48 ABD Doları) ve her kitlesel pazar ürünü sonunda zinciri unutur ve her şey için merkezi bir çözüm alır.
İkincisi olmadan, kullanıcılar fonlarını (ve finansal olmayan varlıklarını) depolama konusunda isteksiz olacağından ve hepsi merkezi borsalara taşınacağından Ethereum başarısız olur.
Üçüncüsü olmadan, Ethereum başarısız olur, çünkü tüm işlemler (ve POAP'ler, vb.) herkesin görmesi için halka açık olur, bu da birçok kullanıcı için mahremiyetten fahiş bir fedakarlık olur ve herkes en azından bazı gizli verilere sahip olmak için harekete geçer. çözüm.
Yukarıda belirtilen nedenlerden dolayı, bu üç geçiş kritiktir. Ancak bunları çözmek için gereken yoğun koordinasyon nedeniyle de zorlayıcıdırlar. Sadece protokolün işlevselliğinin iyileştirilmesi gerekmiyor, Ethereum ile etkileşim biçimimizde, uygulamalarda ve cüzdanlarda derin değişiklikler gerektiren oldukça temel değişikliklerin yapılması gereken durumlar var.
Bu üç değişiklik, kullanıcılar ve adresler arasındaki ilişkide devrim yaratacak
L2 genişletilmiş bir dünyada, kullanıcılar birçok L2'de var olacaktır. İyimserlik üzerine olan ExampleDAO'ya üye misiniz? O zaman Optimism'de bir hesabınız var! ZkSync'in stablecoin sisteminde CDP'ye sahip misiniz? O halde ZkSync'te bir hesabınız var! 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üşüme göre dört yerde ETH'm var. Evet, Arbitrum ve Arbitrum Nova farklıdır. Endişelenme, bu zamanla daha da karmaşıklaşacak!
Akıllı sözleşme cüzdanları daha fazla karmaşıklık ekleyerek L1 ve çeşitli L2'lerde aynı adrese sahip olmayı zorlaştırır. Bugün, çoğu kullanıcı, adresleri aslında imzayı doğrulamak için kullanılan genel anahtarın karması 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 bir adresi korumak daha zor hale gelir. Başta CREATE2 ve ERC-2470 tekil fabrikalar olmak üzere ağ genelinde adresleri bir kod karması eşdeğeri yapmaya çalışmak için birçok çalışma yapılmış olsa da, bunu mükemmel bir şekilde yapmak çok zordu. Bazı L2'ler ("tip 4 ZK-EVM'ler" gibi), EVM'lere tam olarak eşdeğer değildir, genellikle bunun yerine Sağlamlık veya bir ara düzenek kullanarak karma denkliğini önler. 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 ele aldığımız adres türlerini değiştirebilir. Kullanıcı başına yalnızca birkaç adres veya L2 başına bir adres yerine özel adres önerisi yaygın olarak kullanılıyorsa, işlem başına bir adres olabilir. Tornado Cash gibi mevcut olanlar da dahil olmak üzere diğer gizlilik programları, varlıkların nasıl farklı şekilde saklandığını 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 adres sistemine güvenmesi gerekir.
Gördüğümüz gibi, üç vardiya, "tek kullanıcı ~= tek adres" zihinsel modelini farklı şekillerde zayıflattı ve bu etkilerin bazıları, vardiyaları uygulamanın karmaşıklığını geri besledi. İki özel komplikasyon şunlardır:
Birine ödeme yapmak istiyorsanız, onlara ödeme yapma bilgilerini nasıl edinirsiniz?
Bir kullanıcı birçok varlığı farklı zincirlerde farklı yerlerde depolarsa, anahtar değiştirme ve sosyal kurtarmayı nasıl gerçekleştirir?
Üç geçiş, zincir üstü ödemelerle (ve kimlikle) ilgilidir
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 Taiko'dan sadece bozuk para alacaksın. ben ne yaparım?
Temel olarak iki çözüm vardır:
Alıcı cüzdan (bir tüccar veya sadece normal bir birey olabilir), fonları eşzamansız olarak entegre etmek için bazı otomatik işlevlerle her L2'yi desteklemeye çalışır.
Alıcı, L2'sini ve adresini sağlar ve gönderenin cüzdanı, fonları otomatik olarak bir çeşit L2 arası köprüleme sistemi aracılığıyla hedef L2'ye yönlendirir.
Elbette bu çözümler birleştirilebilir: alıcı, kabul etmeye istekli olduğu L2 listesini sağlar ve gönderenin cüzdanı, doğrudan (şansları varsa) veya L2 boyunca köprülü bir yol aracılığıyla göndermeyi içerebilen ödemeyi hesaplar.
Ancak bu, üç vardiyanın getirdiği temel zorluğun yalnızca bir örneği: birine ödeme yapmak kadar basit bir şey, yalnızca 20 baytlık bir adresten daha fazla bilgi gerektirmeye başlar.
Akıllı sözleşme cüzdanlarına geçiş, neyse ki adres sistemine fazla yük getirmedi, ancak uygulama yığınının diğer bölümlerinde ele alınması gereken bazı teknik sorunlar var. Cüzdanların, işlemlerde yalnızca 21000 gas göndermediğinden emin olmak için değil, daha da önemlisi, cüzdanın ödeme alan tarafının yalnızca EOA'lardan ETH transferlerini değil, akıllı sözleşme koduyla gönderilen ETH'yi de izlemesini sağlamak için güncellenmesi gerekiyor. 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ı ayrıca bazı şeyleri kolaylaştıracaktır - özellikle, birisi yalnızca ETH olmayan ERC20 belirteçlerini kabul ederse, bu belirteçle benzin için ödeme yapmak için bir ERC-4337 ödemesini kullanabilecektir.
Öte yandan, mahremiyet, henüz tam olarak çözemediğimiz büyük sorunları yeniden ortaya çıkarıyor. Orijinal Tornado Cash, dahili transferleri desteklemediği için bu sorunları ortaya çıkarmadı: kullanıcılar yalnızca sisteme para yatırabilir ve para çekebilirdi. Dahili aktarımlar gerçekleştirebildiğinizde, kullanıcıların gizlilik sisteminin dahili adres şemasını kullanması gerekir. 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 sözü içermesi ve (ii) gönderenin yalnızca şifreli bir mesaj göndermesi gerekir. alıcı, alıcıların ödemeleri keşfetmesine yardımcı olmanın yolunun şifresini çözebilir.
Gizlilik adresi protokolü, şu şekilde çalışan bir meta adres kavramına dayanır: meta adresin bir kısmı, gönderenin harcama anahtarının gizli bir versiyonudur ve diğer kısım, gönderenin şifreleme anahtarıdır (minimum uygulamalar olmasına rağmen). Bunu ayarlayabilir Her iki tuş da aynıdır).
Buradaki temel ders, gizlilik odaklı 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 gerektiğidir. Ödemenin yanı sıra, bu yönde genişlemek için başka iyi nedenler de var. Örneğin, Ethereum'da şifrelenmiş e-posta istiyorsak, kullanıcıların herkese açık bir şekilde bir tür şifreleme anahtarı sağlaması gerekir. "EOA dünyasında", bunu başarmak için hesap anahtarlarını yeniden kullanabiliriz, ancak güvenli akıllı sözleşme cüzdanları dünyasında, muhtemelen bunu başarmak için daha belirgin işlevselliğe sahip olmalıyız. Bu aynı zamanda Ethereum tabanlı kimliklerin, Ethereum merkezli olmayan merkezi olmayan gizlilik ekosistemleriyle daha uyumlu hale getirilmesine yardımcı olacaktır, en belirgin örnek PGP anahtarlarıdır.
Üç dönüşüm ve anahtar kurtarma
Bir kullanıcının birden çok adresine sahip olabileceği bir dünyada, temel değişiklikleri ve sosyal kurtarmayı uygulamanın varsayılan yolu, kullanıcının her adres için ayrı ayrı kurtarma yordamları gerçekleştirmesini sağlamaktır. Bu, tek bir tıklama ile yapılabilir: cüzdanlar, tüm kullanıcıların adreslerinde aynı anda kurtarma prosedürlerini gerçekleştirmek için yazılım içerebilir. Bununla birlikte, bu tür bir UX basitleştirmesinde bile, saf çoklu adres kurtarmada üç sorun vardır:
Gerçekçi olmayan gaz faturaları: Bu, kendisi için konuşuyor.
Karşı Olgusal Adres: Akıllı sözleşmesi henüz yayınlanmamış bir adres (aslında bu, henüz para göndermediğiniz bir hesap anlamına gelir). Bir kullanıcı olarak, potansiyel olarak sonsuz sayıda karşıolgusal adrese sahipsiniz: henüz var olmayan L2'ler dahil olmak üzere her L2'de bir veya daha fazla ve steganografik adres şemasından türetilen tamamen farklı bir sonsuz karşıolgusal adres kümesi.
Gizlilik: Bir kullanıcının kasıtlı olarak birbirine bağlamamak için birçok adresi varsa, kesinlikle aynı anda veya yaklaşık olarak geri yükleyerek hepsini herkese açık bir şekilde bağlamak istemezler!
Bu sorunları çözmek zordur. Neyse ki, oldukça iyi performans gösteren oldukça zarif bir çözüm var: doğrulama mantığını varlık tutmadan ayıran bir mimari.
Her kullanıcının bir konumda bulunan bir anahtar deposu sözleşmesi vardır (ana ağ veya belirli bir L2 olabilir). Kullanıcılar daha sonra farklı L2'lerde adreslere sahiptir; burada her adres için doğrulama mantığı, anahtar deposu sözleşmesine yönelik bir işaretçidir. Bu adreslerden yapılan harcamalar, geçerli (veya daha gerçekçi bir ifadeyle, en yeni) harcama genel anahtarını gösteren anahtar deposu sözleşmesinde bir kanıt gerektirecektir.
Kanıt çeşitli şekillerde elde edilebilir:
Doğrudan L2'de salt okunur L1 erişimi. L2, onlara L1'in durumunu doğrudan okumaları için bir yol verecek şekilde 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.
Merkel şubesi. Merkle şubeleri, L1 durumlarını L2'ye veya L2 durumlarını L1'e kanıtlayabilir veya bir L2 durumunun parçalarını başka bir L2'ye kanıtlamak 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'nin altına düşecektir.
ZK-SNARK'lar. Şubelerin kendileri yerine Merkle şubelerinin ZK-SNARK'larını kullanarak veri maliyetlerini düşürebilirsiniz. Zincir dışı toplama teknikleri (örn. EIP-4337'ye dayalı), tek bir ZK-SNARK'ın tüm zincirler arası durum kanıtlarını tek bir blokta doğrulaması için oluşturulabilir.
KZG Taahhüdü. L2 veya bunun üzerine inşa edilmiş şemalar, bu sistem içindeki durum kanıtlarının yalnızca 48 bayt uzunluğunda olmasına izin veren sıralı bir adresleme sistemi sunabilir. ZK-SNARK'lar gibi, çoklu kanıt şeması, 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, daha hafif bir çözüm uygulayabiliriz, yalnızca kurtarma sırasında çapraz L2 kanıtı yapmamız gerekir. Bir hesaptan yapılan harcama, ilgili ortak anahtarın hesapta saklandığı bir harcama anahtarına bağlı olacaktır, ancak kurtarma, anahtar deposundaki mevcut harcama ortak anahtarını kopyalayan bir işlem gerektirecektir. Karşı-olgusal bir adresteki fonlar, eski anahtarınız şu olmasa bile güvendedir: bir karşı-olgusal adresi "etkinleştirmek", onu çalışan bir sözleşmeye dönüştürmek, mevcut harcama ortak anahtarını kopyalayan bir L2 arası kanıt yapmayı gerektirecektir. Güvenli forumlardaki bu başlık, benzer bir mimarinin nasıl çalışabileceğini açıklar.
Böyle bir şemaya gizlilik eklemek için, sadece işaretçiyi şifrelememiz ve ardından ZK-SNARK'lardaki tüm ispatları yapmamız gerekiyor:
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. Ancak, bu programlar arasında birçok potansiyel sinerji vardır. Örneğin, bir "anahtar deposu sözleşmesi" kavramı, önceki bölümde bahsedilen "adres" sorununa da bir çözüm olabilir: Kullanıcıların, anahtarlarını güncellediklerinde değişmeyen kalıcı adreslere sahip olmalarını istiyorsak, biz gizli meta adresleri, şifreleme anahtarları ve diğer bilgileri bir anahtar deposu sözleşmesine koymak ve anahtar deposu sözleşmesinin adresini kullanıcının "adresi" olarak kullanmak mümkündür.
Pek çok ikincil altyapının güncellenmesi gerekiyor
ENS kullanmak pahalıdır. Bugün, Haziran 2023, işler o kadar da kötü değil: işlem ücretleri yüksek olsa da ENS alan ücretleriyle karşılaştırılabilir. zuzalu.eth'e kaydolmak bana yaklaşık 27 dolara mal oldu ve bunun 11 doları işlem ücreti. Ancak başka bir boğa piyasamız varsa, ücretler fırlayacak. ETH fiyat artışı olmasa bile, gas ücretinin 200 gwei'ye geri döndürülmesi, alan adı kaydı için işlem ücretini 104$'a çıkarır. Bu nedenle, insanların ENS'yi gerçekten kullanmasını istiyorsak, özellikle kullanıcıların neredeyse ücretsiz kayıt istediği merkezi olmayan sosyal medya gibi kullanım durumları için (bu platformlar, kullanıcıları için alt alanlar sağladığından ENS alan ücretleri sorun değildir), L2'de ENS Çalışmalarına ihtiyacımız var. .
Neyse ki, ENS ekibi zaten hareket halinde ve L2'deki ENS gerçekten oluyor! ERC-3668 ("CCIP standardı" olarak da bilinir), ENSIP-10 ile birlikte, herhangi bir L2'de ENS alt alanlarını otomatik olarak doğrulamak için bir yöntem sağlar. CCIP standardı, L2 verilerinin kanıtlarını doğrulamak için bir yöntemi açıklayan bir akıllı sözleşme kurulmasını gerektirir ve alan adları (örneğin, Optimnames için ecc.eth) böyle bir sözleşmenin kontrolü altına alınabilir. CCIP sözleşmesi L1'de ecc.eth'i kontrol ettikten sonra, bazı subdomain.ecc.eth'e erişmek, otomatik olarak söz konusu alt etki alanını fiilen saklayan kanıtın (örn. Merkle şubesi) L2 durumunu bulmayı ve doğrulamayı içerecektir.
Aslında kanıt elde etmek, sözleşmede saklanan bir dizi URL'ye erişmeyi içerir; bu, kuşkusuz merkezileştirme gibi hissettirir, ancak bunun aslında olmadığını iddia etsem de: bu bir 1-of-N güven modelidir (geçersiz kanıtlar CCIP tarafından engellenir. sözleşmenin geri arama işlevindeki mantık, geçerli bir kanıt döndüren bir URL olduğu sürece sorun olmadığını yakalar). Bu URL listesi düzinelerce URL içerebilir.
ENS CCIP'in çalışması bir başarı öyküsüdür ve ihtiyacımız olan radikal reformun mümkün olduğunun bir işareti olarak görülmelidir. Ancak uygulama düzeyinde daha fazla reforma ihtiyaç var. Bazı örnekler şunları içerir:
Birçok dapp, zincir dışı imzalar sağlamak için kullanıcılara güvenir. Harici Sahiplikli Hesaplar (EOA'lar) için 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 desteklemiyor; desteklemeleri gerekiyor.
Kullanıcılar ve sözleşmeler arasında ayrım yapmak için (örneğin, aktarımları önlemek veya telif ücretlerini uygulamak için) "Bu EOA mı?" Genel olarak, tamamen teknik bir çözüm bulmaya çalışmamanızı tavsiye ederim; belirli bir kriptografik kontrol transferinin faydalı bir menfaat transferi olup olmadığını anlama sorusu, zincir dışı bir topluluğa başvurmadan çözülemeyecek zor bir sorudur. güdümlü mekanizmalar Sonraki çöz. Büyük olasılıkla, uygulamaların transferleri engellemeye daha az, Harberger vergisi gibi tekniklere daha fazla dayanması gerekecek.
Cüzdanların harcama ve şifreleme anahtarlarıyla nasıl etkileşime girdiğinin iyileştirilmesi gerekecek. Ş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 (örneğin, uygulama adının bir karması) imzalanır ve özel anahtar olmadan üretilemeyen bir nonce oluşturulur. , bu nedenle 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ı gerekir.
Hafif istemciler (örn. Helios), yalnızca L1'i değil, L2'yi doğrulamak zorunda kalacaktır. Bugün hafif istemciler, L1 başlığının geçerliliğini kontrol etmeye (hafif istemci senkronizasyon protokolünü kullanarak) ve L1 başlığından kaynaklanan işlemlerin L1 durumunu ve Merkle çatallarını doğrulamaya odaklanmaktadır. Yarın, L1'de saklanan durum kökünden kaynaklanan L2 durumunun kanıtını da doğrulamaları gerekiyor (bu daha gelişmiş sürüm aslında L2'nin ön onayına bakıyor).
Cüzdanların varlıkları ve verileri koruması gerekir
Şimdi, cüzdanın işi varlıkları korumaktır. Her şey zincir üzerindedir ve cüzdanın koruması gereken tek şey şu anda bu varlıkları koruyan özel anahtarlardır. Anahtarları değiştirirseniz, önceki özel anahtarınızı ertesi gün internette güvenle yayınlayabilirsiniz. Ancak, sıfır bilgi kanıtlarının olduğu bir dünyada durum artık böyle değil: cüzdanlar yalnızca kimlik doğrulama bilgilerini korumakla kalmıyor, verilerinizi de koruyor.
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ın, "Zuzalu'da ikamet ettiğimi kanıtlayın, ancak hangisi olduğunu açıklamayın" gibi temel kanıtları yapmak için kullanılabilecek, sistemin kimliğini doğrulamak için kullandıkları bir özel anahtarı vardır. Bununla birlikte, Zupass sistemi, üzerine inşa edilmiş başka uygulamalara da sahip olmaya başladı, en önemlisi Stamps (Zupass'ın POAP versiyonu).
Team Cat'in gururlu bir üyesi olduğumu kanıtlayan birçok Zupass pulumdan biri.
Damgaların POAP'ler üzerinden sunduğu temel özellik, damgaların özel olmasıdır: verileri yerel olarak tutarsınız ve damgayı (veya üzerindeki bazı hesaplamaları) yalnızca sizin hakkınızda bu bilgilere sahip olmalarını istiyorsanız kanıtlarsınız. Ancak bu, riski artırır: Bu bilgiyi kaybederseniz, damganızı kaybedersiniz.
Elbette, verileri tutma sorunu, bir kriptografik anahtarı tutma sorununa indirgenir: üçüncü bir taraf (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. Tersine, birisi şifreleme anahtarınızı görürse, o anahtarla şifrelenmiş her şeyi görebilir.
Zupass'ın fiili çözümü, insanları anahtarlarını birden fazla cihazda (örneğin, dizüstü bilgisayar ve telefon) saklamaya teşvik etmektir, çünkü aynı anda hepsini kaybetme şansları zayıftır. Bir adım daha ileri gidebilir ve anahtarı depolamak için gizli bir paylaşım kullanabilir, anahtarı birden fazla gözetmen arasında paylaştırabiliriz.
MPC yoluyla bu sosyal iyileşme, cüzdanlar için yeterli bir çözüm değildir, çünkü bu, yalnızca mevcut vasilerin değil, aynı zamanda önceki vasilerin de varlıklarınızı çalmak için anlaşabileceği anlamına gelir ki bu kabul edilemez bir yüksek risktir. Bununla birlikte, mahremiyet ihlali genellikle varlıkların tamamen kaybolmasından daha az risk taşır ve birisi mahremiyeti yüksek düzeyde koruyan bir kullanım senaryosuna ihtiyaç duyarsa, gizlilik gerektiren ilişkili anahtarları yedeklemeyerek daha yüksek bir kayıp riskini kabul edebilir. eylemlerin korunması.
Çoklu kurtarma yollarından oluşan karmaşık bir sistemle kullanıcıları bunaltmaktan kaçınmak için, sosyal kurtarmayı destekleyen cüzdanların hem varlık kurtarmayı hem de şifreleme anahtarı kurtarmayı yönetmesi gerekebilir.
Kimlik sorusuna geri dön
Bu değişikliklerin ortak bir teması, zincir üzerinde "sizi" temsil eden bir kriptografik tanımlayıcı olarak kullandığınız bir "adres" kavramının kökten değişmesi gerektiğidir. "Benimle nasıl etkileşime geçileceğine dair talimatlar" artık yalnızca bir ETH adresi değil; birden çok L2'deki birden çok adresin, gizli meta adreslerin, şifreleme anahtarlarının ve bir biçimde diğer verilerin bir kombinasyonunu içermelidirler.
Bunu yapmanın bir yolu, 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, o kişi bunu öğrenebilir ve öğrenebilir. daha karmaşık kesişen ve gizliliği koruyan yollar da dahil olmak üzere, ödeme yapan ve sizinle etkileşime giren her şey.
Ancak, bu ENS merkezli yaklaşımın iki zayıf yönü vardır:
Adına çok fazla şey bağlar. Adınız siz değilsiniz, adınız birçok özelliğinizden sadece biri. Tüm kimlik profilinizi taşımadan ve birçok uygulamada bir grup kaydı güncellemeden adınızı değiştirebilmelisiniz.
Güvenilmeyen karşı olgusal isimlere 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 tavuk-yumurta sorunu vardır: zincirle etkileşim, işlem ücretlerinin ödenmesini gerektirir ve ücretlerin ödenmesi, zaten madeni paraya sahip olmayı gerektirir. CREATE2 ile akıllı sözleşme adresleri dahil olmak üzere ETH adresleri bu özelliğe sahiptir. ENS adı öyle değil çünkü iki Bob da kendilerinin bob.ecc.eth zincir dışı olduğuna karar verirse, adı hangisinin alacağını seçmenin bir yolu yok.
Muhtemel bir çözüm, bu yazının başlarında mimaride bahsedilen anahtar deposu sözleşmesine daha fazla öğe koymaktır. Anahtar deposu sözleşmesi, sizinle ve onunla nasıl etkileşim kurduğunuzla ilgili (bazıları zincir dışı olabilen CCIP aracılığıyla) çeşitli bilgiler içerebilir ve kullanıcılar, anahtar deposu sözleşmelerini birincil tanımlayıcı olarak kullanabilir. Ancak aldıkları gerçek varlıklar, çeşitli farklı yerlerde saklanacaktır. Anahtar deposu sözleşmeleri adlara bağlı değildir, karşı olgusaldır: yalnızca bazı sabit başlangıç parametreleriyle bir anahtar deposu sözleşmesi tarafından başlatılabilen bir adres oluşturabilirsiniz.
Başka bir çözüm kategorisi, ruhen Bitcoin ödeme protokolüne benzeyen kullanıcı odaklı adresler kavramını terk etmekle ilgilidir. 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 ödemeleri istediği şekilde kullanabileceği bir talep bağlantısı (açık bir URL veya QR kodu olarak) gönderebilir.
İlk hareket eden ister gönderen ister alıcı olsun, gerçek zamanlı olarak doğrudan 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) ve pratikte gönderici ile alıcı arasında doğrudan iletişim varsayımı çok zor bir problemdir, bu nedenle farklı teknolojilerin bir kombinasyonuna bakabiliriz.
Tüm bu tasarımlarda, her şeyi merkezi olmayan ve kullanıcılar için anlaşılır kılmak çok önemlidir. Kullanıcıların mevcut varlıklarının en güncel görünümüne ve kendilerine yönelik yayınlanmış bilgilere kolayca ulaşabilmesini sağlamamız gerekiyor. Bu görüşler, özel çözümler yerine açık araçlara dayanmalıdır. Daha karmaşık bir ödeme altyapısının, geliştiricilerin neler olup bittiğini anlaması ve onu yeni ortama uyarlaması için 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.
Geri bildirimleri, incelemeleri ve önerileri için Dan Finlay, Karl Floersch, David Hoffman ve Scroll ve SoulWallet ekiplerine özel teşekkürler.