Yazar: Rui S, SevenX Ventures; Derleyen: Deep Wave TechFlow
tanıtmak
Harici Sahipli Hesaplardan (EOA) Akıllı Sözleşme Hesaplarına (SCA) geçiş hızla artıyor ve Vitalik'in kendisi de dahil olmak üzere pek çok meraklı tarafından destekleniyor. Heyecana rağmen SCA'nın benimsenmesi EOA kadar yaygın değildi. Temel sorunlar arasında ayı piyasası zorlukları, geçiş endişeleri, imza sorunları, gaz yükü ve en önemlisi mühendislik zorlukları yer alıyor.
Hesap Soyutlamanın (AA) en önemli avantajlarından biri, kodu kullanarak işlevselliği özelleştirebilme yeteneğidir. Bununla birlikte, büyük bir mühendislik sorunu, AA işlevselliğinin birlikte çalışamamasıdır ve bu parçalanma, entegrasyonu engeller ve satıcıya bağımlı kalmanın kapısını açar. Ayrıca, özellikleri aynı anda yükseltirken ve birleştirirken güvenliğin sağlanması karmaşık olabilir.
Modüler hesap soyutlaması, akıllı hesapları özel işlevlerinden ayırmaya yönelik yenilikçi bir yaklaşım olan daha geniş AA hareketinin bir alt kümesi olarak ortaya çıktı. Amaç, çeşitli işlevlere sahip, güvenli, sorunsuz bir şekilde entegre edilmiş cüzdanlar geliştirmek için modüler bir yapı oluşturmaktır. Gelecekte, cüzdanların ve dApp'lerin artık işlevler oluşturmaya değil, kullanıcı deneyimine odaklanmasını sağlamak için ücretsiz bir akıllı sözleşme hesabı "uygulama mağazası" uygulayabilir.
AA Kısa Açıklama
Geleneksel EOA, tohum cümleleri, gaz, zincirler arası ve çoklu işlemler gibi birçok zorluğu beraberinde getirir. Hiçbir zaman karmaşıklık yaratmayı amaçlamadık, ancak gerçek şu ki blockchain kitleler için kolay bir oyun değil.
Hesap soyutlama, akıllı sözleşme hesaplarından yararlanır, programlanabilir doğrulama ve yürütmeye olanak tanır, kullanıcıların her bir işlemi imzalayıp yayınlamak yerine bir dizi işlemi aynı anda onaylamasına olanak tanır ve daha fazla işlevsellik sağlar. Kullanıcı deneyimine (ör. Gaz soyutlama ve oturum anahtarları), maliyete (ör. toplu işlemler) ve güvenliğe (ör. sosyal kurtarma, çoklu imza) faydalar sağlar. Şu anda hesap soyutlamayı uygulamanın iki yolu vardır:
Protokol katmanı: Bazı protokollerin kendileri yerel hesap soyutlama desteği sağlar.ZKsync işlemleri, ister EOA ister SCA'dan olsun, aynı süreci takip eder, AA'yı desteklemek için tek bir bellek havuzu ve işlem süreci kullanır, Starknet ise EOA'yı ve tüm hesapları kaldırır. Her ikisi de SCA'dır ve Argent gibi yerel akıllı sözleşme cüzdanları var.
Sözleşme katmanı: Ethereum ve eşdeğeri L2 için ERC 4337, konsensüs katmanını değiştirmeden AA'yı desteklemek için ayrı bir işlem girişi sunar. Stackup, Alchemy, Etherspot, Biconomy, Candide ve Plimico gibi projeler paketleyici altyapısı oluştururken Safe, Zerodev, Etherspot ve Biconomy gibi projeler yığınlar ve SDK'lar oluşturuyor.
SCA'nın benimsenmesindeki ikilemler
Hesap Soyutlama (AA) konusu 2015'ten beri tartışılıyor ve bu yıl ERC 4337 tarafından gündeme getirildi. Ancak konuşlandırılan akıllı sözleşme hesaplarının sayısı hala EOA'nınkinden çok daha az.
Bu ikilemi daha derinlemesine inceleyelim:
Ayı piyasasının etkisi:
Her ne kadar AA kesintisiz oturum açma ve Gaz soyutlama gibi avantajlar getirmiş olsa da, şu anda ayı piyasasını deneyimleyen insanlar yeni kullanıcılardan ziyade çoğunlukla eğitimli EOA kullanıcılarından oluşuyor, dolayısıyla dApp'ler ve cüzdanlar için herhangi bir teşvik yok. Öyle olsa bile, AA sistemlerini ve Gazsız çözümlerini sunarak yalnızca bir ayda yaklaşık 360.000 UserOps (AA işlemi) sağlayan Cyberconnect gibi bazı önde gelen uygulamalar yavaş yavaş AA'yı benimsiyor.
Göçün önündeki engeller:
Kullanıcı ve varlık biriktiren cüzdanlar ve uygulamalar için varlıkların güvenli ve rahat bir şekilde taşınması hâlâ zorlu bir süreç. Ancak EIP-7377 gibi girişimler, EOA'ların tek seferlik geçiş işlemleri başlatmasına olanak tanıyor.
*İmza sorunu:
Akıllı sözleşmenin kendisi doğal olarak mesajları imzalayamaz çünkü EOA gibi özel bir anahtara sahip değildir. ERC 1271 gibi çabalar bu tür bir imzalamayı mümkün kılıyor ancak mesaj imzalama ilk işleme kadar işe yaramıyor, bu da karşı olgusal dağıtımları kullanan cüzdanlar için zorluk teşkil ediyor. Ambire tarafından önerilen ERC-6492, ERC-1271'in geriye dönük uyumlu halefidir ve önceki sorunları çözebilir.
*Gaz yükü:
SCA'yı dağıtmak, simüle etmek ve yürütmek, standart EOA'dan daha yüksek maliyetlere neden olur. Bu evlat edinmenin önünde bir engel haline gelir. Ancak bu maliyetleri azaltmak için hesap oluşturmayı kullanıcı eylemlerinden ayırmak, hesap tuzlarını ve varlık kontrollerini ortadan kaldırmak gibi bazı testler yapılmıştır.
Mühendislik sorunları:
ERC-4337 ekibi, geliştiricilere temel uygulamaları sağlamak için eth-infinitiism deposunu kurdu. Ancak farklı kullanım durumlarında daha ayrıntılı veya spesifik işlevlere daldıkça entegrasyon ve kod çözme zorlaşıyor.
Bu makalede beşinci konuyu daha derinlemesine ele alacağız: mühendislik zorlukları.
Mühendislik sorunlarını çözmek için modüler akıllı sözleşme hesapları
Mühendislik zorluklarının daha ayrıntılı bir açıklaması aşağıdaki gibidir:
Parçalanma: Çeşitli özellikler artık belirli SCA'lar veya bağımsız eklenti sistemleri aracılığıyla farklı şekillerde etkinleştiriliyor. Her biri kendi standartlarını takip ederek geliştiricileri hangi platformların destekleneceğine karar vermeye zorluyor. Bu, platformun kilitlenmesine veya çabanın tekrarlanmasına yol açabilir.
Güvenlik: Hesaplar ve özellikler arasındaki esneklik avantaj sağlarken aynı zamanda güvenlik kaygılarını da artırabilmektedir. Özellikler toplu olarak denetlenebilir ancak bağımsız değerlendirmenin olmaması hesap ihlali riskini artırabilir.
Yükseltilebilirlik: İşlevsellik geliştikçe işlevsellik ekleme, değiştirme veya kaldırma olanağını korumak önemlidir. Her güncellemede mevcut işlevselliğin yeniden dağıtılması karmaşıklığa neden olur.
Bu sorunların üstesinden gelmek için, güvenli ve verimli yükseltmeler sağlamak üzere yükseltilebilir sözleşmelere, genel geliştirme verimliliğini artırmak için yeniden kullanılabilir çekirdeklere ve sözleşme hesaplarının farklı ön uçlar arasında sorunsuz bir şekilde geçiş yapabilmesini sağlamak için standartlaştırılmış arayüzlere ihtiyacımız var.
Bu terimler ortak bir konseptte birleşiyor: modüler bir hesap soyutlama mimarisi (Modüler AA) oluşturmak.
Modüler AA, hizmetleri kullanıcılara göre uyarlamak ve geliştiricilerin minimum kısıtlamayla işlevselliği sorunsuz bir şekilde geliştirmelerine olanak sağlamak için akıllı hesapların modüler hale getirilmesini öngören daha geniş AA hareketi içindeki bir niştir.
Ancak yeni standartların oluşturulması ve desteklenmesi her sektörde büyük bir zorluktur. Herkesin ana çözümü kabul etmesinden önce, ilk aşamalarda birçok farklı çözüm ortaya çıkabilir. Ancak hem 4337 SDK'nın hem de cüzdan geliştiricilerinin, altyapı ekiplerinin ve protokol tasarımcılarının bu süreci hızlandırmak için birlikte çalışması cesaret verici.
Modüler yapı: ana hesap ve modüller
Delege çağrısı ve vekil sözleşmesi
Harici çağrılar ve temsilci çağrıları:
Temsilci çağrı, çağrıya benzese de, hedef sözleşmeyi kendi bağlamında yürütmek yerine, hedef sözleşmeyi çağıran sözleşmenin mevcut durumunda yürütür. Bu, hedef sözleşme tarafından yapılan herhangi bir durum değişikliğinin çağıran sözleşmenin deposuna uygulanacağı anlamına gelir.
Şekillendirilebilir ve yükseltilebilir yapıların uygulanabilmesi için "acente sözleşmeleri" adı verilen temel bir bilgiye ihtiyaç vardır.
Aracı sözleşmesi: Sıradan sözleşmeler mantıklarını ve durumlarını saklar ve dağıtımdan sonra güncellenemez. Bir vekil sözleşme, başka bir sözleşmeyi çağırmak için bir temsilci kullanır. Aracı sözleşmesinin mevcut durumunda yürütülen bir işlevi referansla uygulayın.
Kullanım örneği: Proxy sözleşmesi aynı kalsa da proxy'nin arkasında yeni uygulamalar dağıtabilirsiniz. Proxy sözleşmeleri yükseltilebilirlik için kullanılır ve halka açık blok zincirlerde dağıtılması ve bakımı daha ucuzdur.
Güvenlik Mimarisi
Safe, geliştiricilerin çeşitli uygulamalar ve cüzdanlar oluşturmasına olanak tanıyan, savaşta kanıtlanmış güvenlik ve esneklik sağlamak üzere tasarlanmış lider bir modüler akıllı hesap altyapısıdır. Pek çok ekibin Safe'in üzerine inşa ettiğini veya Safe'den ilham aldığını belirtmekte fayda var. Biconomy, Safe'de yerel 4337 ve 1/1 çoklu imzayı genişleterek hesabını kullanıma sunuyor. Uygulanan 164.000'den fazla sözleşme ve 30,7 milyar doların üzerinde kilitli değer ile Safe, şüphesiz bu alanda en iyi seçimdir.
Güvenli yapı
Güvenli hesap sözleşmesi: ana acente sözleşmesi (durum bilgisi olan)
Güvenli hesap bir vekil sözleşmesidir çünkü temsilci çağrısı tekil bir sözleşmedir. Güvenli hesap, aracı için değişkenler olarak ayarlanan ve dolayısıyla durumunu tanımlayan sahip, eşik ve uygulama adresini içerir.
Singleton sözleşmesi: entegrasyon merkezi (vatansız)
Singleton, Güvenli hesaba hizmet eder ve eklentiler, kancalar, işlev işleyicileri ve imza doğrulayıcıları dahil olmak üzere farklı entegrasyonları entegre eder ve tanımlar.
Modül sözleşmesi: özel mantık ve işlevler
Modüller çok güçlüdür. Modüler bir tür olan eklentiler, ödeme akışları, kurtarma mekanizmaları ve oturum anahtarları gibi farklı işlevleri tanımlayabilir ve zincir dışı verileri elde ederek Web2 ile Web3 arasında zincirler arası bir köprü görevi görebilir. Kancalar gibi diğer modüller güvenlik görevlileri olarak görev yapar ve işlev işleyicileri her türlü talimata yanıt verir.
Güvenliyi benimsediğimizde ne olur?
Yükseltilebilir sözleşmeler:
Ne zaman yeni bir eklenti tanıtılsa, yeni bir singleton'un konuşlandırılması gerekir. Kullanıcılar, Safe'i tercihlerine ve gereksinimlerine uyacak şekilde istenen tekli sürüme yükseltme özerkliğine sahiptir.
Şekillendirilebilir ve yeniden kullanılabilir modüller:
Eklentilerin modüler yapısı, geliştiricilerin bağımsız olarak işlevsellik oluşturmasına olanak tanır. Daha sonra bu eklentileri kendi kullanım durumlarına göre seçmekte ve birleştirmekte özgürdürler, bu da son derece özelleştirilebilir bir yaklaşımı kolaylaştırır.
ERC-2535 Elmas Ajan
ERC 2535 ve Diamond Agent Hakkında
ERC 2535, dağıtımdan sonra yükseltilebilen/genişletilebilen ve neredeyse hiçbir boyut kısıtlaması olmayan modüler bir akıllı sözleşme sistemi olan Diamond Agent'ı standart hale getirir. Şimdiye kadar Zerodev'in Kernel ve Soul Wallet deneyleri gibi birçok ekip bundan ilham aldı.
Elmasın yapısı nedir?
Elmas Sözleşme: Ana Temsilci Sözleşmesi (Durum Bilgili) Elmas, uygulamadan itibaren işlevleri delege çağrıları yoluyla çağıran bir vekil sözleşmesidir.
Modüller/eklentiler/özel sözleşmeler: Özel mantık ve işlevsellik (durum bilgisi olmayan) Bir modül veya sözde özellik, işlevselliğini bir veya daha fazla Elmas'a dağıtabilen durum bilgisi olmayan bir sözleşmedir. Bunlar dahili işlevleri, kitaplıkları ve durum değişkenlerini paylaşabilen bağımsız sözleşmelerdir.
Diamond'ı kullandığımızda ne olur?
Yükseltilebilir sözleşmeler: Diamond, farklı eklentileri izole etmek ve birbirine bağlamak ve herhangi bir eklentiyi doğrudan elmasCut işlevi aracılığıyla eklemek/değiştirmek/kaldırmak için sistematik bir yol sağlar. Diamond'a zamanla eklenebilecek eklenti sayısında herhangi bir sınırlama yoktur.
Modüler ve yeniden kullanılabilir eklentiler: Dağıtılmış bir eklenti herhangi bir sayıda Diamond tarafından kullanılabilir, böylece dağıtım maliyetleri büyük ölçüde azalır.
Güvenli akıllı hesap ile Diamond yöntemi arasındaki fark
Safe ve Diamond mimarileri arasında pek çok benzerlik vardır; her ikisi de temel olarak proxy sözleşmelerine dayanır ve yükseltilebilirlik ve modülerlik için mantık sözleşmelerine referans verir.
Ancak temel fark mantıksal sözleşmelerin işlenmesinde yatmaktadır. İşte daha ayrıntılı talimatlar:
Esneklik: Yeni eklentiler etkinleştirildiğinde, Safe'in aracısındaki değişiklikleri uygulamak için tekil sözleşmesini yeniden dağıtması gerekir. Buna karşılık Diamond bunu doğrudan temsilcisindeki elmasCut işlevi aracılığıyla yapar. Yaklaşımdaki bu farklılık, Safe'in daha yüksek düzeyde kontrole sahip olduğu, Diamond'ın ise daha fazla esneklik ve modülerlik sağladığı anlamına gelir.
Güvenlik: Şu anda her iki yapıda da temsilci çağrısı kullanılıyor ve bu, harici kodun ana sözleşmenin deposunu yönetmesine olanak tanıyor. Safe mimarisinde, temsilci çağrısı tek bir mantıksal sözleşmeye işaret ederken Diamond, birden fazla modül sözleşmesi (eklentiler) arasında temsilci çağrısını kullanır. Bu nedenle, kötü amaçlı bir eklentinin başka bir eklentinin üzerine yazması ve dolayısıyla aracının bütünlüğünü tehlikeye atabilecek depolama çakışmaları riskini ortaya çıkarması mümkündür.
Maliyet: Diamond yaklaşımının doğasında bulunan esneklik, artan güvenlik endişelerini de beraberinde getiriyor. Bu, bir maliyet faktörü ekler ve her yeni eklenti eklendiğinde tam bir denetim gerektirir. Önemli olan, bu eklentilerin birbirlerinin işlevlerine müdahale etmemesini sağlamaktır; bu, güçlü güvenlik standartlarını korumaya çalışan küçük ve orta ölçekli işletmeler için zorlayıcı olabilir.
"Güvenli Akıllı Hesap Yöntemi" ve "Diamond Yöntemi", aracı ve modülleri içeren farklı yapılara örnektir. Esneklik ve güvenliğin nasıl dengeleneceği kritik öneme sahiptir ve iki yaklaşımın gelecekte birbirini tamamlaması muhtemeldir.
Modül sırası: doğrulayıcı, yürütücü ve Kanca
Alchemy ekibi tarafından önerilen, Diamond'dan ilham alan ve ERC-4337 için özel olarak uyarlanan ERC 6900 standardını tanıtarak tartışmamızı genişletelim. Ortak bir arayüz sağlayarak ve eklenti ile cüzdan geliştiricileri arasındaki işi koordine ederek akıllı hesaplardaki modülerlik sorununu çözer.
AA'nın işlem süreci söz konusu olduğunda üç ana süreç vardır: Doğrulama, Yürütme ve Kanca. Daha önce tartıştığımız gibi bu adımlar, bir proxy hesabı kullanılarak modülün çağrılması yoluyla yönetilebilir. Farklı projeler farklı isimler kullansa da benzer bir temel mantığı yakalamak önemlidir.
Doğrulama: Arayanın hesabının orijinalliğinden ve yetkisinden emin olun.
Yürütme: Hesabın izin verdiği herhangi bir özel mantığı yürütün.
*Hook: Başka bir fonksiyondan önce veya sonra çalışan bir modül olarak. Durumu değiştirebilir veya çağrının tamamının geri alınmasına neden olabilir.
Modülleri farklı mantıklara göre ayırmak çok önemlidir. Standartlaştırılmış bir yaklaşım, akıllı sözleşme hesabı doğrulama, yürütme ve Kanca işlevlerinin nasıl yazılması gerektiğini belirtmelidir. İster Safe ister ERC 6900 olsun, standardizasyon, belirli bir uygulama veya ekosistem için benzersiz geliştirme çabalarına olan ihtiyacın azaltılmasına yardımcı olur ve satıcıya bağımlı kalmayı önler.
Modül keşfi ve güvenliği
Gelişmekte olan çözümlerden biri, kullanıcıların doğrulanabilir modülleri keşfetmesine olanak tanıyan, "kayıt defteri" diyebileceğimiz bir yer oluşturmayı içeriyor. Bu kayıt defteri, basitleştirilmiş ancak gelişen bir modüler pazar yerini kolaylaştırmak için tasarlanmış bir "uygulama mağazasına" benzer.
Güvenli{Çekirdek}Protokol
Safe{Core} Protokolü, güçlü güvenliği korurken, çeşitli satıcılar ve geliştiriciler için açıkça tanımlanmış standartlar ve kurallar aracılığıyla erişilebilirliği artırmak üzere tasarlanmış açık kaynaklı, birlikte çalışabilen bir akıllı sözleşme hesap protokolüdür.
Hesap: Safe{Core} protokolünde hesap kavramı esnektir ve belirli bir uygulamayla sınırlandırılmaz. Bu, çeşitli hesap hizmeti sağlayıcılarının katılmasına olanak tanır.
Yönetici: Yönetici, hesaplar, kayıtlar ve modüller arasında koordinatör görevi görür. Ayrıca izin katmanı görevi görerek güvenlikten de sorumludur.
Kayıt Defteri: Kayıt defteri, keşif ve güvenlik için açık bir "uygulama mağazası" ortamı oluşturmayı amaçlayan, güvenlik özelliklerini tanımlar ve ERC 6900 gibi modül standartlarını uygular.
Modüller: Modüller işlevselliği yönetir ve eklentiler, Kancalar, imza doğrulayıcılar ve işlev işleyicileri dahil olmak üzere çeşitli başlangıç türlerinde sağlanır. Geliştiriciler, belirlenmiş standartları karşıladıkları sürece buna katkıda bulunabilirler.
Yapay Elmas Tasarımı
Süreç şu şekilde gelişiyor:
Şema tanımı oluşturun: şema, kanıt için önceden tanımlanmış bir veri yapısı görevi görür. Kuruluşlar modeli kendi özel kullanım durumlarına göre özelleştirebilir.
Bir kalıba dayalı bir modül oluşturun: akıllı sözleşme bir modül olarak kaydedilir, bayt kodunu alır ve kalıp kimliğini seçer. Bu veriler daha sonra kayıt defterinde saklanır.
Modül kanıtlarını edinin: Sertifika verenler/denetçiler şemaya dayalı olarak modüller için kanıt sağlayabilirler. Bu sertifikalar, benzersiz tanımlayıcılar (UID'ler) ve bağlantı için diğer sertifikalara referanslar içerebilir. Zincir üzerinde yayılabilirler ve hedef zincirde belirli eşiklerin karşılandığını doğrulayabilirler.
Karmaşık mantığı uygulamak için ayrıştırıcıları kullanın: ayrıştırıcılar isteğe bağlı olarak modelde ayarlanır. Modül oluşturma, kanıt oluşturma ve sökme sırasında çağrılabilirler. Bu ayrıştırıcılar, geliştiricilerin kanıtın yapısını korurken karmaşık ve çeşitli mantıkları birleştirmelerine olanak tanır.
Kullanıcı dostu sorgu erişimi: Sorgu, kullanıcıların güvenlik bilgilerine ön uçtan erişmesi için bir yol sağlar. EIP'yi burada bulabilirsiniz.
Bu model henüz başlangıç aşamasında olmasına rağmen, merkezi olmayan ve işbirlikçi bir şekilde bir standart oluşturma potansiyeline sahiptir. Kayıtları, geliştiricilerin modüllerini kaydetmesine, denetçilerin güvenliklerini doğrulamasına, cüzdanların entegre edilmesine ve kullanıcıların modülleri kolayca bulmasına ve onay bilgilerini doğrulamasına olanak tanır. Gelecekte aşağıdaki kullanımlar olabilir:
Sertifikasyon Kuruluşu: Safe gibi güvenilir kuruluşlar, dahili modüller için sertifikalandırma kuruluşu olarak Rhinestone ile işbirliği yapabilir. Aynı zamanda bağımsız kanıtlayıcılar da katılabilir.
Modül geliştiricileri: Açık pazarın oluşmasıyla modül geliştiricilerin çalışmalarını kayıt yoluyla ticarileştirmeleri mümkün olur.
Kullanıcılar: Cüzdanlar veya dApp'ler gibi kullanıcı dostu arayüzler aracılığıyla kullanıcılar, modül bilgilerini görüntüleyebilir ve farklı kanıtlayıcılara güven verebilir.
"Modül kaydı" kavramı, eklenti ve modül geliştiricileri için karlı fırsatlar sağlar. Aynı zamanda bir "modül pazarının" da önünü açabilir. Bu yönlerden bazıları Safe ekibi tarafından denetlenebilirken diğerleri herkesi katkıda bulunmaya davet eden ve şeffaf bir denetim izi sağlayan merkezi olmayan pazarlar olarak kendini gösterebilir. Bu yaklaşımı benimseyerek satıcıya bağımlı kalmayı önleyebilir ve daha geniş bir kitleye hitap eden daha iyi bir kullanıcı deneyimi sunarak EVM'nin genişlemesini destekleyebiliriz.
Bu yöntemler bireysel modüllerin güvenliğini sağlasa da akıllı sözleşme hesaplarının genel güvenliği kesinlikle güvenilir değildir. Meşru modülleri birleştirmek ve depolama çakışmaları olmadığını kanıtlamak zor olabilir; bu tür sorunların çözümünde cüzdanların veya AA altyapısının önemi vurgulanıyor.
Özetle
Cüzdan sağlayıcıları ve dApp'ler, modüler bir akıllı sözleşme hesap yığınından yararlanarak teknik bakımın karmaşıklığından kurtulabilir. Aynı zamanda harici modül geliştiricileri, bireysel ihtiyaçlara uygun profesyonel hizmetler sunma fırsatına sahiptir. Ancak çözülmesi gereken zorluklar arasında esneklik ve güvenlik arasında bir denge kurulması, modüler standartların geliştirilmesinin desteklenmesi ve kullanıcıların Akıllı Hesaplarını kolayca yükseltmesine ve değiştirmesine olanak tanıyan standartlaştırılmış arayüzlerin uygulanması yer alıyor.
Ancak modüler akıllı sözleşme hesapları (SCA), benimseme bulmacasının yalnızca bir parçasıdır. SCA'nın potansiyelini tam olarak gerçekleştirmek için, ikinci katman çözümlerinden protokol katmanı desteğinin yanı sıra güçlü paketleyici altyapısı ve eşler arası bellek havuzları, daha uygun maliyetli ve uygulanabilir SCA imzalama mekanizmaları, zincirler arası SCA senkronizasyonu da gereklidir. ve yönetimin yanı sıra kullanıcı dostu arayüzler geliştirmek.
Geniş katılımın olduğu ve bazı ilginç soruları gündeme getiren bir gelecek tasavvur ediyoruz: SCA sipariş süreci yeterince kârlı hale geldiğinde, geleneksel madenci çıkarılabilir değer (MEV) mekanizmaları alana nasıl girecek, paketleyiciler oluşturacak ve değer yakalayacak? Altyapı olgunlaştığında Hesap Soyutlaması (AA) nasıl "amaca dayalı" işlemler için temel katman haline gelebilir? Bu alan sürekli geliştiği için lütfen bizi izlemeye devam edin.
View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
Modüler akıllı sözleşme hesap tasarımına ilişkin derinlemesine tartışma: uygulamadaki teknik sorunların çözümü
Yazar: Rui S, SevenX Ventures; Derleyen: Deep Wave TechFlow
tanıtmak
Harici Sahipli Hesaplardan (EOA) Akıllı Sözleşme Hesaplarına (SCA) geçiş hızla artıyor ve Vitalik'in kendisi de dahil olmak üzere pek çok meraklı tarafından destekleniyor. Heyecana rağmen SCA'nın benimsenmesi EOA kadar yaygın değildi. Temel sorunlar arasında ayı piyasası zorlukları, geçiş endişeleri, imza sorunları, gaz yükü ve en önemlisi mühendislik zorlukları yer alıyor.
Hesap Soyutlamanın (AA) en önemli avantajlarından biri, kodu kullanarak işlevselliği özelleştirebilme yeteneğidir. Bununla birlikte, büyük bir mühendislik sorunu, AA işlevselliğinin birlikte çalışamamasıdır ve bu parçalanma, entegrasyonu engeller ve satıcıya bağımlı kalmanın kapısını açar. Ayrıca, özellikleri aynı anda yükseltirken ve birleştirirken güvenliğin sağlanması karmaşık olabilir.
Modüler hesap soyutlaması, akıllı hesapları özel işlevlerinden ayırmaya yönelik yenilikçi bir yaklaşım olan daha geniş AA hareketinin bir alt kümesi olarak ortaya çıktı. Amaç, çeşitli işlevlere sahip, güvenli, sorunsuz bir şekilde entegre edilmiş cüzdanlar geliştirmek için modüler bir yapı oluşturmaktır. Gelecekte, cüzdanların ve dApp'lerin artık işlevler oluşturmaya değil, kullanıcı deneyimine odaklanmasını sağlamak için ücretsiz bir akıllı sözleşme hesabı "uygulama mağazası" uygulayabilir.
AA Kısa Açıklama
Geleneksel EOA, tohum cümleleri, gaz, zincirler arası ve çoklu işlemler gibi birçok zorluğu beraberinde getirir. Hiçbir zaman karmaşıklık yaratmayı amaçlamadık, ancak gerçek şu ki blockchain kitleler için kolay bir oyun değil.
Hesap soyutlama, akıllı sözleşme hesaplarından yararlanır, programlanabilir doğrulama ve yürütmeye olanak tanır, kullanıcıların her bir işlemi imzalayıp yayınlamak yerine bir dizi işlemi aynı anda onaylamasına olanak tanır ve daha fazla işlevsellik sağlar. Kullanıcı deneyimine (ör. Gaz soyutlama ve oturum anahtarları), maliyete (ör. toplu işlemler) ve güvenliğe (ör. sosyal kurtarma, çoklu imza) faydalar sağlar. Şu anda hesap soyutlamayı uygulamanın iki yolu vardır:
SCA'nın benimsenmesindeki ikilemler
Hesap Soyutlama (AA) konusu 2015'ten beri tartışılıyor ve bu yıl ERC 4337 tarafından gündeme getirildi. Ancak konuşlandırılan akıllı sözleşme hesaplarının sayısı hala EOA'nınkinden çok daha az.
Bu ikilemi daha derinlemesine inceleyelim:
Her ne kadar AA kesintisiz oturum açma ve Gaz soyutlama gibi avantajlar getirmiş olsa da, şu anda ayı piyasasını deneyimleyen insanlar yeni kullanıcılardan ziyade çoğunlukla eğitimli EOA kullanıcılarından oluşuyor, dolayısıyla dApp'ler ve cüzdanlar için herhangi bir teşvik yok. Öyle olsa bile, AA sistemlerini ve Gazsız çözümlerini sunarak yalnızca bir ayda yaklaşık 360.000 UserOps (AA işlemi) sağlayan Cyberconnect gibi bazı önde gelen uygulamalar yavaş yavaş AA'yı benimsiyor.
Kullanıcı ve varlık biriktiren cüzdanlar ve uygulamalar için varlıkların güvenli ve rahat bir şekilde taşınması hâlâ zorlu bir süreç. Ancak EIP-7377 gibi girişimler, EOA'ların tek seferlik geçiş işlemleri başlatmasına olanak tanıyor.
*İmza sorunu:
Akıllı sözleşmenin kendisi doğal olarak mesajları imzalayamaz çünkü EOA gibi özel bir anahtara sahip değildir. ERC 1271 gibi çabalar bu tür bir imzalamayı mümkün kılıyor ancak mesaj imzalama ilk işleme kadar işe yaramıyor, bu da karşı olgusal dağıtımları kullanan cüzdanlar için zorluk teşkil ediyor. Ambire tarafından önerilen ERC-6492, ERC-1271'in geriye dönük uyumlu halefidir ve önceki sorunları çözebilir.
*Gaz yükü:
SCA'yı dağıtmak, simüle etmek ve yürütmek, standart EOA'dan daha yüksek maliyetlere neden olur. Bu evlat edinmenin önünde bir engel haline gelir. Ancak bu maliyetleri azaltmak için hesap oluşturmayı kullanıcı eylemlerinden ayırmak, hesap tuzlarını ve varlık kontrollerini ortadan kaldırmak gibi bazı testler yapılmıştır.
ERC-4337 ekibi, geliştiricilere temel uygulamaları sağlamak için eth-infinitiism deposunu kurdu. Ancak farklı kullanım durumlarında daha ayrıntılı veya spesifik işlevlere daldıkça entegrasyon ve kod çözme zorlaşıyor.
Bu makalede beşinci konuyu daha derinlemesine ele alacağız: mühendislik zorlukları.
Mühendislik sorunlarını çözmek için modüler akıllı sözleşme hesapları
Mühendislik zorluklarının daha ayrıntılı bir açıklaması aşağıdaki gibidir:
Bu sorunların üstesinden gelmek için, güvenli ve verimli yükseltmeler sağlamak üzere yükseltilebilir sözleşmelere, genel geliştirme verimliliğini artırmak için yeniden kullanılabilir çekirdeklere ve sözleşme hesaplarının farklı ön uçlar arasında sorunsuz bir şekilde geçiş yapabilmesini sağlamak için standartlaştırılmış arayüzlere ihtiyacımız var.
Bu terimler ortak bir konseptte birleşiyor: modüler bir hesap soyutlama mimarisi (Modüler AA) oluşturmak.
Modüler AA, hizmetleri kullanıcılara göre uyarlamak ve geliştiricilerin minimum kısıtlamayla işlevselliği sorunsuz bir şekilde geliştirmelerine olanak sağlamak için akıllı hesapların modüler hale getirilmesini öngören daha geniş AA hareketi içindeki bir niştir.
Ancak yeni standartların oluşturulması ve desteklenmesi her sektörde büyük bir zorluktur. Herkesin ana çözümü kabul etmesinden önce, ilk aşamalarda birçok farklı çözüm ortaya çıkabilir. Ancak hem 4337 SDK'nın hem de cüzdan geliştiricilerinin, altyapı ekiplerinin ve protokol tasarımcılarının bu süreci hızlandırmak için birlikte çalışması cesaret verici.
Modüler yapı: ana hesap ve modüller
Delege çağrısı ve vekil sözleşmesi
Harici çağrılar ve temsilci çağrıları:
Temsilci çağrı, çağrıya benzese de, hedef sözleşmeyi kendi bağlamında yürütmek yerine, hedef sözleşmeyi çağıran sözleşmenin mevcut durumunda yürütür. Bu, hedef sözleşme tarafından yapılan herhangi bir durum değişikliğinin çağıran sözleşmenin deposuna uygulanacağı anlamına gelir.
Şekillendirilebilir ve yükseltilebilir yapıların uygulanabilmesi için "acente sözleşmeleri" adı verilen temel bir bilgiye ihtiyaç vardır.
Güvenlik Mimarisi
Safe, geliştiricilerin çeşitli uygulamalar ve cüzdanlar oluşturmasına olanak tanıyan, savaşta kanıtlanmış güvenlik ve esneklik sağlamak üzere tasarlanmış lider bir modüler akıllı hesap altyapısıdır. Pek çok ekibin Safe'in üzerine inşa ettiğini veya Safe'den ilham aldığını belirtmekte fayda var. Biconomy, Safe'de yerel 4337 ve 1/1 çoklu imzayı genişleterek hesabını kullanıma sunuyor. Uygulanan 164.000'den fazla sözleşme ve 30,7 milyar doların üzerinde kilitli değer ile Safe, şüphesiz bu alanda en iyi seçimdir.
Güvenli yapı
Güvenli hesap bir vekil sözleşmesidir çünkü temsilci çağrısı tekil bir sözleşmedir. Güvenli hesap, aracı için değişkenler olarak ayarlanan ve dolayısıyla durumunu tanımlayan sahip, eşik ve uygulama adresini içerir.
Singleton, Güvenli hesaba hizmet eder ve eklentiler, kancalar, işlev işleyicileri ve imza doğrulayıcıları dahil olmak üzere farklı entegrasyonları entegre eder ve tanımlar.
Modüller çok güçlüdür. Modüler bir tür olan eklentiler, ödeme akışları, kurtarma mekanizmaları ve oturum anahtarları gibi farklı işlevleri tanımlayabilir ve zincir dışı verileri elde ederek Web2 ile Web3 arasında zincirler arası bir köprü görevi görebilir. Kancalar gibi diğer modüller güvenlik görevlileri olarak görev yapar ve işlev işleyicileri her türlü talimata yanıt verir.
Güvenliyi benimsediğimizde ne olur?
Ne zaman yeni bir eklenti tanıtılsa, yeni bir singleton'un konuşlandırılması gerekir. Kullanıcılar, Safe'i tercihlerine ve gereksinimlerine uyacak şekilde istenen tekli sürüme yükseltme özerkliğine sahiptir.
Eklentilerin modüler yapısı, geliştiricilerin bağımsız olarak işlevsellik oluşturmasına olanak tanır. Daha sonra bu eklentileri kendi kullanım durumlarına göre seçmekte ve birleştirmekte özgürdürler, bu da son derece özelleştirilebilir bir yaklaşımı kolaylaştırır.
ERC-2535 Elmas Ajan
ERC 2535 ve Diamond Agent Hakkında
ERC 2535, dağıtımdan sonra yükseltilebilen/genişletilebilen ve neredeyse hiçbir boyut kısıtlaması olmayan modüler bir akıllı sözleşme sistemi olan Diamond Agent'ı standart hale getirir. Şimdiye kadar Zerodev'in Kernel ve Soul Wallet deneyleri gibi birçok ekip bundan ilham aldı.
Elmasın yapısı nedir?
Diamond'ı kullandığımızda ne olur?
Güvenli akıllı hesap ile Diamond yöntemi arasındaki fark
Safe ve Diamond mimarileri arasında pek çok benzerlik vardır; her ikisi de temel olarak proxy sözleşmelerine dayanır ve yükseltilebilirlik ve modülerlik için mantık sözleşmelerine referans verir.
Ancak temel fark mantıksal sözleşmelerin işlenmesinde yatmaktadır. İşte daha ayrıntılı talimatlar:
"Güvenli Akıllı Hesap Yöntemi" ve "Diamond Yöntemi", aracı ve modülleri içeren farklı yapılara örnektir. Esneklik ve güvenliğin nasıl dengeleneceği kritik öneme sahiptir ve iki yaklaşımın gelecekte birbirini tamamlaması muhtemeldir.
Modül sırası: doğrulayıcı, yürütücü ve Kanca
Alchemy ekibi tarafından önerilen, Diamond'dan ilham alan ve ERC-4337 için özel olarak uyarlanan ERC 6900 standardını tanıtarak tartışmamızı genişletelim. Ortak bir arayüz sağlayarak ve eklenti ile cüzdan geliştiricileri arasındaki işi koordine ederek akıllı hesaplardaki modülerlik sorununu çözer.
AA'nın işlem süreci söz konusu olduğunda üç ana süreç vardır: Doğrulama, Yürütme ve Kanca. Daha önce tartıştığımız gibi bu adımlar, bir proxy hesabı kullanılarak modülün çağrılması yoluyla yönetilebilir. Farklı projeler farklı isimler kullansa da benzer bir temel mantığı yakalamak önemlidir.
Modülleri farklı mantıklara göre ayırmak çok önemlidir. Standartlaştırılmış bir yaklaşım, akıllı sözleşme hesabı doğrulama, yürütme ve Kanca işlevlerinin nasıl yazılması gerektiğini belirtmelidir. İster Safe ister ERC 6900 olsun, standardizasyon, belirli bir uygulama veya ekosistem için benzersiz geliştirme çabalarına olan ihtiyacın azaltılmasına yardımcı olur ve satıcıya bağımlı kalmayı önler.
Modül keşfi ve güvenliği
Gelişmekte olan çözümlerden biri, kullanıcıların doğrulanabilir modülleri keşfetmesine olanak tanıyan, "kayıt defteri" diyebileceğimiz bir yer oluşturmayı içeriyor. Bu kayıt defteri, basitleştirilmiş ancak gelişen bir modüler pazar yerini kolaylaştırmak için tasarlanmış bir "uygulama mağazasına" benzer.
Güvenli{Çekirdek}Protokol
Safe{Core} Protokolü, güçlü güvenliği korurken, çeşitli satıcılar ve geliştiriciler için açıkça tanımlanmış standartlar ve kurallar aracılığıyla erişilebilirliği artırmak üzere tasarlanmış açık kaynaklı, birlikte çalışabilen bir akıllı sözleşme hesap protokolüdür.
Yapay Elmas Tasarımı
Süreç şu şekilde gelişiyor:
Bu model henüz başlangıç aşamasında olmasına rağmen, merkezi olmayan ve işbirlikçi bir şekilde bir standart oluşturma potansiyeline sahiptir. Kayıtları, geliştiricilerin modüllerini kaydetmesine, denetçilerin güvenliklerini doğrulamasına, cüzdanların entegre edilmesine ve kullanıcıların modülleri kolayca bulmasına ve onay bilgilerini doğrulamasına olanak tanır. Gelecekte aşağıdaki kullanımlar olabilir:
"Modül kaydı" kavramı, eklenti ve modül geliştiricileri için karlı fırsatlar sağlar. Aynı zamanda bir "modül pazarının" da önünü açabilir. Bu yönlerden bazıları Safe ekibi tarafından denetlenebilirken diğerleri herkesi katkıda bulunmaya davet eden ve şeffaf bir denetim izi sağlayan merkezi olmayan pazarlar olarak kendini gösterebilir. Bu yaklaşımı benimseyerek satıcıya bağımlı kalmayı önleyebilir ve daha geniş bir kitleye hitap eden daha iyi bir kullanıcı deneyimi sunarak EVM'nin genişlemesini destekleyebiliriz.
Bu yöntemler bireysel modüllerin güvenliğini sağlasa da akıllı sözleşme hesaplarının genel güvenliği kesinlikle güvenilir değildir. Meşru modülleri birleştirmek ve depolama çakışmaları olmadığını kanıtlamak zor olabilir; bu tür sorunların çözümünde cüzdanların veya AA altyapısının önemi vurgulanıyor.
Özetle
Cüzdan sağlayıcıları ve dApp'ler, modüler bir akıllı sözleşme hesap yığınından yararlanarak teknik bakımın karmaşıklığından kurtulabilir. Aynı zamanda harici modül geliştiricileri, bireysel ihtiyaçlara uygun profesyonel hizmetler sunma fırsatına sahiptir. Ancak çözülmesi gereken zorluklar arasında esneklik ve güvenlik arasında bir denge kurulması, modüler standartların geliştirilmesinin desteklenmesi ve kullanıcıların Akıllı Hesaplarını kolayca yükseltmesine ve değiştirmesine olanak tanıyan standartlaştırılmış arayüzlerin uygulanması yer alıyor.
Ancak modüler akıllı sözleşme hesapları (SCA), benimseme bulmacasının yalnızca bir parçasıdır. SCA'nın potansiyelini tam olarak gerçekleştirmek için, ikinci katman çözümlerinden protokol katmanı desteğinin yanı sıra güçlü paketleyici altyapısı ve eşler arası bellek havuzları, daha uygun maliyetli ve uygulanabilir SCA imzalama mekanizmaları, zincirler arası SCA senkronizasyonu da gereklidir. ve yönetimin yanı sıra kullanıcı dostu arayüzler geliştirmek.
Geniş katılımın olduğu ve bazı ilginç soruları gündeme getiren bir gelecek tasavvur ediyoruz: SCA sipariş süreci yeterince kârlı hale geldiğinde, geleneksel madenci çıkarılabilir değer (MEV) mekanizmaları alana nasıl girecek, paketleyiciler oluşturacak ve değer yakalayacak? Altyapı olgunlaştığında Hesap Soyutlaması (AA) nasıl "amaca dayalı" işlemler için temel katman haline gelebilir? Bu alan sürekli geliştiği için lütfen bizi izlemeye devam edin.