*Editörün notu: Akıllı Sözleşme Hesapları (SCA'lar) ivme kazanıyor ve Vitalik de dahil olmak üzere birçok çekirdek girişimci tarafından destekleniyor, ancak SCA'nın benimsenmesinde hala birçok zorluk var. Hesap Soyutlaması (AA), kod özelleştirmesini kullanma avantajına sahiptir, ancak birlikte çalışamazlığı, tümleştirme ve satıcıya kilitlenme sorunlarına neden olur. Modüler hesap soyutlama, çok yönlü, güvenli ve sorunsuz bir şekilde entegre edilmiş cüzdanlar geliştirmek için modüler bir yapı oluşturmayı amaçlar. *
SevenX Ventures >'da bir yatırımcı olan Rui, SCA'yı benimsemenin önündeki en önemli beş zorluğu (ayı piyasası etkisi, geçiş zorluğu, imza sorunları, yüksek gaz maliyetleri ve mühendislik zorlukları) belirledi ve bunları daha ayrıntılı olarak tartıştı. Ek olarak, modüler akıllı sözleşme hesaplarının mimarisinin analizi, modüler SCA'nın benimseme zorluklarının yalnızca küçük bir parçası olduğuna işaret ediyor.
SCA'nın tam potansiyelini gerçekleştirmek için, ek protokol katmanı desteği, sağlam paketleyici altyapısı ve eşler arası bellek havuzları, daha uygun maliyetli ve uygulanabilir bir SCA imza mekanizması, zincirler arası SCA senkronizasyonu ve yönetimi ve kullanıcı dostu arayüzlerin geliştirilmesi için Katman 2 çözümlerine ihtiyaç vardır.
Mevcut zorluklar çözüldükçe ve daha fazla insan SCA'yı benimsedikçe gelecekte ne olacak? Rui ayrıca bazı ilginç sorular soruyor. BlockBeats, orijinal metni şu şekilde derledi:
Harici olarak sahip olunan hesaplardan (EOA) akıllı sözleşme hesaplarına (SCA'lar) geçiş ivme kazanıyor ve Vitalik de dahil olmak üzere birçok çekirdek girişimci tarafından destekleniyor. Buna rağmen, SCA'nın benimsenmesi EOA'nınki kadar yaygın olmamıştır. Temel konular arasında ayı piyasasının etkisi, EOA'yı SCA'ya taşımanın zorluğu, imza sorunları, yüksek gaz maliyetleri ve en önemlisi geliştirme zorlukları yer alıyor.
Hesap Soyutlama'nın (AA) en önemli avantajı, kod kullanarak işlevselliği özelleştirme yeteneğidir. Bununla birlikte, AA işlevselliğinin birlikte çalışamaması, bu parçalanma AA entegrasyonunu engellediğinden ve satıcıya bağımlılığı güçlendirdiğinden büyük bir zorluk teşkil etmektedir. Ayrıca, yükseltilebilir ve birleştirilebilir olurken güvenliği sağlamak da önemli bir zorluktur.
Modüler hesap soyutlamasının ortaya çıkışı, akıllı hesapları özel özelliklerinden ayıran yenilikçi bir yaklaşım olan AA trendinde bir niş. Amaç, birden fazla özelliğe, güvenliğe ve sorunsuz entegrasyona sahip cüzdanlar geliştirmek için modüler bir yapı oluşturmaktı. Gelecekte, modüler hesap soyutlama, ücretsiz bir akıllı sözleşme hesabı "uygulama mağazasını" etkinleştirecek ve cüzdanların ve dApp'lerin özellikler oluşturmak için çok fazla çaba harcamak yerine kullanıcı deneyimini iyileştirmeye odaklanmasına olanak tanıyacak.
Kısa Hesap Soyutlama (AA)
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
Geleneksel EOA, insanların blok zincirine maruz kalmasına tohum ifadeleri, gaz ücretleri, zincirler arası işlemler ve çoklu işlemler gibi birçok zorluk getirir.
Hesap soyutlama, programlanabilir doğrulama ve kullanıma izin vermek için akıllı sözleşme hesaplarından yararlanır. Bu, kullanıcıların her işlemi imzalamak ve yayınlamak zorunda kalmadan bir dizi işlemi bir kerede onaylayabilecekleri anlamına gelir. Hesap soyutlama, iyileştirilmiş kullanıcı deneyimi (örneğin, gaz soyutlaması ve oturum anahtarları), azaltılmış maliyetler (örneğin, toplu işlemler) ve gelişmiş güvenlik (örneğin, sosyal kurtarma, çoklu imza) gibi daha fazla özelliği de etkinleştirebilir. Şu anda, hesapları soyutlamanın iki yolu vardır:
· Protokol katmanı: Bazı protokoller yerel olarak yerel hesap soyutlama desteği sağlar, ZKSync işlemleri AA'yı desteklemek için tek bir bellek havuzu ve işlem akışı kullanır, hem EOA hem de SCA'dan aynı süreci takip ederken, Starknet EOA'yı kaldırmıştır, tüm hesaplar SCA'dır ve Argent gibi yerel akıllı sözleşme cüzdanlarına sahiptirler.
· Sözleşme katmanı: Ethereum ve benzeri L2'ler için ERC4337, konsensüs katmanını değiştirmeden AA'yı desteklemek için ayrı bir mempool tanıttı. Stackup, Alchemy, Etherspot, Biconomy, Candide ve Plimico gibi yerler paketleyici altyapısı oluştururken, Safe, Zerodev, Etherspot ve Biconomy gibi şeyler paketleyiciler ve SDK'lar oluşturuyor.
SCA'yı benimseme ikilemi
Hesap soyutlama (AA) konusu 2015'ten beri tartışılmaktadır ve bu yıl ERC 4337 ile daha da ön plana çıkarılmıştır. Bununla birlikte, konuşlandırılan akıllı sözleşme hesaplarının sayısı hala EOA kadar düşük değil.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Bu ikilemi inceleyelim:
Ayı piyasasının etkisi
AA'nın sorunsuz oturum açma ve gaz çıkarma gibi avantajlarına rağmen, tüm kullanıcıların eğitimli EOA kullanıcıları olduğu ve çok fazla yeni kullanıcının olmadığı mevcut ayı piyasasında, dApp'lerin ve cüzdanların SCA'yı benimsemesi için herhangi bir teşvik yoktur. Buna rağmen, önde gelen dApp'lerden bazıları, AA sistemlerini ve gazsız çözümlerini tanıtarak yalnızca bir ayda yaklaşık 360.000 UserOps (AA işlemi) sağlayan Cyberconnect gibi AA'yı kademeli olarak benimsiyor.
Göç engelleri
Halihazırda kullanıcı ve varlık biriktirmiş cüzdanlar ve uygulamalar için, varlıkları güvenli ve rahat bir şekilde taşımak bir zorluk olmaya devam ediyor. Ancak, EIP-7377 gibi bir şema, EOA'nın tek seferlik bir geçiş işlemi başlatmasına izin verir.
İmza sorunları
Akıllı sözleşmenin kendisi, EOA gibi özel bir anahtara sahip olmadığı için mesajları imzalayamaz. ERC1271 gibi girişimler bunu mümkün kılar, ancak mesaj imzalama ilk işleme kadar çalışmaz ve bu da karşı olgularla dağıtılan cüzdanlar için bir zorluk teşkil eder. Ambire tarafından önerilen ERC-6492, ERC-1271'in geriye dönük uyumlu halefidir ve önceki sorunu çözebilir.
Gaz maliyeti
Standart EOA'ya kıyasla SCA'yı dağıtma, simüle etme ve yürütme maliyetinin daha yüksek olması da benimsemenin önünde bir engeldir. Ancak, hesap oluşturmayı kullanıcı eylemlerinden ayırmak, bir hesapla ilişkili "tuzu" ortadan kaldırmak ve daha fazlası gibi bazı testler yapılmıştır.
Mühendislik problemleri
ERC-4337 ekibi, geliştiriciler için temel bir uygulama sağlayan bir eth-infinitism deposu oluşturdu. Bununla birlikte, geliştiriciler farklı kullanım durumları için daha ayrıntılı ve belirli özelliklere ölçeklendikçe, entegrasyon ve kod çözme daha fazla zorlukla karşı karşıya kalmaktadır. Bu yazıda, mühendislik zorluklarını inceleyeceğiz.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Modüler akıllı sözleşme hesaplarıyla mühendislik zorluklarını çözün
Mühendislik zorlukları üç açıdan daha ayrıntılı olarak açıklanabilir: parçalanma, güvenlik ve yükseltilebilirlik.
· Parçalanma: Özellikler artık belirli bir SCA veya bağımsız bir eklenti sistemi aracılığıyla çeşitli şekillerde etkinleştirilebilir. Her platform ve hizmet sağlayıcı kendi standartlarını takip ederek geliştiricilerin hangi platformları ve hizmet sağlayıcıları destekleyeceklerine karar vermelerini ister. Bu, potansiyel platform (satıcı) kilitlenmesine veya gereksiz çalışmaya yol açabilir.
· Güvenlik: Hesapların ve işlevlerin birbirinden ayrılması esneklik avantajı sağlarken, güvenlik sorunlarını daha ciddi hale getirebilir. Tüm özellikler birlikte gözden geçirilebileceğinden, bağımsız bir değerlendirmenin olmaması hesap güvenlik açığı riskini artırabilir.
· Yükseltilebilirlik: Hesabınız büyüdükçe, özellik ekleme, değiştirme veya kaldırma olanağını korumak önemlidir ve mevcut özellikleri yeniden dağıtan her güncelleştirme karmaşıklığa neden olur.
Bu sorunları çözmek için, güvenli ve verimli yükseltmeler sağlamak için yükseltilebilir sözleşmelere, genel geliştirme verimliliğini artırmak için yeniden kullanılabilir çekirdeklere ve farklı ön uçlar arasında sorunsuz bir geçiş sağlamak için standartlaştırılmış arayüzlere ihtiyacımız var.
Bu terimler ortak bir kavram üzerinde birleşir: modüler bir hesap soyutlama mimarisi (Modüler AA) oluşturmak.
Modüler hesap soyutlama, kullanıcılara özelleştirilmiş hizmetler sağlamak ve geliştiricilerin minimum kısıtlamayla işlevselliği sorunsuz bir şekilde geliştirmelerini sağlamak için akıllı hesapların modülerleştirilmesini öngören daha geniş AA geliştirmesinin bir alt bölümüdür.
Bununla birlikte, herhangi bir sektörde yeni standartlar oluşturmak ve teşvik etmek büyük bir zorluktur. Herkes aynı standardı kabul edene kadar, başlangıç aşamasında birçok farklı çözüm ortaya çıkabilir. 4337 SDK, cüzdanlar, altyapı ekipleri veya protokol katmanı tasarımcıları olsun, hesap soyutlamasını iyileştirmek ve teşvik etmek için çalışanların bu süreci hızlandırmak için birlikte çalıştığını görmek cesaret verici.
Modüler yapı: ana hesaplar ve modüller
Hesap, işlevi uygulamak için modülü nasıl çağırır?
Temsilci çağrısı ve proxy sözleşmesi
Harici ve yetkilendirilmiş aramalar:
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
Temsilci çağrıları hakkında
"Yetkilendirilmiş çağrı", "çağrı"ya benzer olsa da, hedef sözleşme bağlamında değil, çağrı sözleşmesinin mevcut durumu bağlamında yürütülür. Bu, hedef sözleşme tarafından yapılan herhangi bir durum değişikliğinin, arayan sözleşmenin depolanmasını değiştireceği anlamına gelir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Proxy sözleşmeleri ve temsilci çağrıları
**Birleştirilebilir ve yükseltilebilir bir yapı elde etmek için, temel bir "acentelik sözleşmesi" kavramının tanıtılması gerekir. **
Proxy sözleşmesi: Normal bir sözleşme mantığını ve durumunu depolar ve dağıtımdan sonra güncelleştirilemez. Proxy sözleşmesi, temsilci çağrısı kullanılarak başka bir sözleşmeye dağıtılır. İşlevi, proxy sözleşmesinin geçerli durumunda yürütmek için başvuruya göre uygulayın.
Kullanım örneği: Proxy sözleşmesi aynı kalırken, aracının arkasında yeni bir uygulama dağıtabilirsiniz. Proxy sözleşmeleri yükseltilebilir ve halka açık blok zincirlerinde dağıtılması ve sürdürülmesi daha ucuzdur.
Güvenli Mimari! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Güvenli mimari
Güvenli Olan: Safe, savaşta test edilmiş güvenlik ve esneklik sağlamak için tasarlanmış önde gelen modüler akıllı hesap altyapısıdır ve geliştiricilerin çeşitli uygulamalar ve cüzdanlar oluşturmasına olanak tanır. Birçok ekip, Safe'in üzerine (veya Safe'den ilham alarak) uygulamalar geliştiriyor. Örneğin, Biconomy, akıllı sözleşme hesabını başlattığında Safe'i yerel 4337 ve 1/1 multisig ile genişletti. 164.000'den fazla sözleşmenin dağıtımına tanık olan ve 30,7 milyar doların üzerinde değere kilitlenen Safe, şüphesiz kendi alanında liderdir.
Safe'in yapısı bir güvenli hesap sözleşmesi, bir tekil sözleşme ve bir modül sözleşmesi içerir.
Proxy sözleşmesi: Durum bilgisi olan
Temsilci olarak atanan çağrı tekil bir sözleşme olduğundan güvenli hesap bir proxy sözleşmesidir. Bir güvenlik hesabı, sahip, eşik ve uygulama adresinin tümünün aracı olarak ayarlandığı ve durumlarının bunlara göre tanımlandığı değişkenler içerir.
单例合约(singleton contract):Integration Hub(无状态)
Tekil sözleşme, Güvenli hesaplara hizmet eder ve Eklenti, Kanca, İşlev İşleyici ve İmza Doğrulayıcı dahil olmak üzere farklı modül sözleşme entegrasyonlarını tanımlar.
Modüller: Özel mantık ve işlevsellik
Modül sözleşmeleri güçlüdür. Modüler türler olarak eklentiler, ödeme akışları, kurtarma mekanizmaları ve oturum anahtarları gibi farklı işlevleri tanımlayabilir ve zincir dışı verileri getirerek Web2 ile Web3 arasında bir köprü görevi görebilir. Güvenlik görevlileri olarak Hooks ve Function Handlers gibi diğer modüller herhangi bir komuta yanıt verebilir.
Safe'in kullanılmaya başlanmasından bu yana değişen değişiklikler:
Yükseltilebilir sözleşmeler: Yeni bir eklenti piyasaya sürüldüğünde, yeni bir singleton'un dağıtılması gerekir. Kullanıcı, Safe'i istenen tekil sürüme yükseltme özerkliğini korur.
Birleştirilebilir, yeniden kullanılabilir modüller: Eklentilerin modüler yapısı, geliştiricilerin özellikleri bağımsız olarak geliştirmesine olanak tanır. Bu eklentileri kullanım durumlarına göre seçmekte ve birleştirmekte özgürdürler, bu da son derece özelleştirilebilir bir yaklaşımla sonuçlanır.
ERC-2535 Elmas 代理
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
ERC2535 Hakkında, Elmas Ajan:
ERC2535 standartlaştırılmış Diamond modeli, neredeyse hiçbir boyut sınırlaması olmaksızın dağıtımdan sonra yükseltilebilen/ölçeklendirilebilen modüler bir akıllı sözleşme sistemidir. Şu anda Zerodev'in Kernel'i ve Soul Wallet'ın deneyleri gibi birçok ekip Diamond yapısından ilham almış durumda.
Pırlanta Yapısı Nedir:**
Diamond Sözleşmesi: Birincil Vekil Sözleşmesi (Stateful) Diamond, bir işlevi uygulamasından çağırmak için yetkilendirilmiş bir çağırma yöntemi kullanan bir vekil sözleşmesidir.
Modül/Eklenti/Faset Sözleşmesi: Özel Mantık ve İşlevsellik (Durumsuz) Bir modül veya sözde Faset, işlevselliğini bir veya daha fazla Elmas'a dağıtabilen durum bilgisi olmayan bir sözleşmedir. Bunlar, içsel işlevleri, kitaplıkları ve durum değişkenlerini paylaşabilen ayrı, bağımsız sözleşmelerdir.
Elmas ile yapılan değişiklikler:
Yükseltilebilir Sözleşmeler: Diamond, farklı eklentileri izole etmek ve bunları birbirine bağlamak, aralarında veri paylaşmak ve ayrıca doğrudan diamondCut özelliğini kullanarak herhangi bir eklentiyi eklemek/değiştirmek/kaldırmak için sistematik bir yol sağlar. Zamanla, Diamond'a eklenebilecek eklenti sayısında bir sınırlama olmayacaktır.
Modüler ve yeniden kullanılabilir eklentiler: Dağıtılan eklentiler herhangi bir sayıda Elmas tarafından kullanılabilir ve bu da dağıtım maliyetlerini önemli ölçüde azaltır.
Güvenli Akıllı Hesap ile Diamond yöntemi arasındaki fark:
Safe ve Diamond mimarileri arasında, her ikisi de yükseltilebilirlik ve modülerlik için temel proxy sözleşmelerine ve referans mantıksal sözleşmelerine dayanan pek çok benzerlik vardır.
İkisi arasındaki temel fark, mantıksal sözleşmelerin ele alınmasıdır. Özellikle:
· Esneklik: Yeni bir eklenti etkinleştirildiğinde, Safe'in proxy'sindeki değişiklikleri uygulamak için tekil sözleşmesini yeniden dağıtması gerekir. Buna karşılık, Diamond bunu doğrudan vekil sözleşmesindeki diamondCut işlevi aracılığıyla gerçekleştirir. Yaklaşımdaki farklılık, Safe'in daha yüksek bir kontrol derecesini koruduğu anlamına gelirken, Diamond gelişmiş esneklik ve modülerlik sunar.
· Güvenli: Şu anda her iki yapıda da kullanılan, harici kodun ana sözleşmenin depolanmasını manipüle etmesine izin verir. Güvenli mimaride, temsilci çağrıları tek bir mantıksal sözleşmeye işaret ederken, Diamond birden çok modül sözleşmesi-eklentisi arasında temsilci çağrıları kullanır. Sonuç olarak, kötü amaçlı bir eklentinin başka bir eklentinin üzerine yazması, depolama çakışmaları riskini ortaya çıkarması ve proxy'nin bütünlüğünü tehlikeye atması mümkündür.
· Maliyet: Diamond yaklaşımında esneklik ve güvenlik bir araya gelir. Bu, maliyeti artırır ve her yeni eklenti eklendiğinde tamamen denetlenmesi gerekir. Önemli olan, bu eklentilerin birbirlerinin işlevselliğine müdahale etmemesini sağlamaktır, bu da özellikle yüksek güvenlik standartlarını korumak için mücadele eden küçük ve orta ölçekli işletmeler için zorlu bir amaçtır.
"Güvenli Akıllı Hesap Yöntemi" ve "Elmas Yöntemi", aracıları ve modülleri içeren farklı yapılara örnektir. Esneklik ve güvenliğin dengelenmesi kritik öneme sahiptir ve bu iki yaklaşım gelecekte gelişmeye ve birbirini tamamlamaya devam edecektir.
Modül Sırası: Doğrulayıcı, Yürütücü ve Kanca
Alchemy ekibinden ERC-4337 için özel olarak uyarlanmış, Diamond'dan ilham alan bir standart olan ERC6900'i tanıtarak bunu daha fazla tartışalım. Ortak bir arayüz sağlayarak akıllı hesap modülerliğinin zorluklarını çözer ve eklenti ile cüzdan geliştiricileri arasındaki çalışmayı koordine eder.
AA'nın işlem süreci söz konusu olduğunda, üç ana süreç vardır: doğrulama, yürütme ve ilişkilendirme. Daha önce tartıştığımız gibi, bu adımların tümü proxy hesabı çağrı modülü kullanılarak yönetilebilir. Farklı projeler farklı isimler kullanabilse de, benzerliğin altında yatan mantığı kavramak önemlidir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Farklı tasarımlarda fonksiyonun adı
Doğrulayıcı: Hesabı arayanın gerçekliğini ve izinlerini sağlar.
Yürütme (UTOR): Hesabın izin verdiği herhangi bir özel mantığı yürütün.
Kanca: Başka bir işlevden önce veya sonra çalışan bir modül görevi görür. Durumu değiştirebilir veya tüm aramayı geri alabilir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Modülleri farklı mantıklara göre ayırmak önemlidir. Standartlaştırılmış yaklaşım, akıllı sözleşme hesapları için doğrulama, yürütme ve ilişkilendirme işlevlerinin nasıl yazılacağını belirtmelidir. İster Güvenli ister ERC6900 olsun, standardizasyon, belirli uygulamalara veya ekosistemlere özgü benzersiz geliştirme çabalarına olan ihtiyacı azaltmaya yardımcı olur ve satıcıya bağımlılığı önler.
Modül keşfi ve güvenliği
Modüller açık bir şekilde nasıl bulunur ve doğrulanır: Geliştirilmekte olan bir çözüm, kullanıcıların "kayıt defteri" olarak adlandırılabilecek doğrulanabilir modülleri keşfetmesine olanak tanıyan bir alan oluşturmayı içerir. Kayıt defteri bir "uygulama mağazası" gibi işlev görür ve basitleştirilmiş ancak gelişen modüler bir pazarı teşvik etmeyi amaçlar.
Safe{Core} 协议
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Safe{Core} protokolü, iyi tanımlanmış standartlar ve kurallar aracılığıyla güçlü güvenliği korurken çok çeşitli satıcılar ve geliştiriciler için erişilebilirliği artırmak üzere tasarlanmış akıllı sözleşme hesapları için açık kaynaklı, birlikte çalışabilir bir protokoldür.
· Hesaplar: Safe{Core} protokolünde, hesap kavramı esnektir ve belirli bir uygulamaya bağlı değildir. Bu, farklı hesap hizmeti sağlayıcılarının dahil olmasına olanak tanır.
· Yönetici: Yönetici, hesaplar, kayıtlar ve modüller arasında bir koordinatör görevi görür. Ayrıca bir lisanslama katmanı olarak güvenlikle de ilgilenir.
· Kayıt defteri: Kayıt defteri, güvenlik özniteliklerini tanımlar ve bulunabilirlik ve güvenlik için açık bir "uygulama mağazası" ortamı oluşturmak için ERC6900 gibi modül standartlarını zorlar.
· 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ürlerine sahiptir. Geliştiriciler, belirlenen kriterleri karşıladıkları sürece dahil olabilirler.
Rhinestone 设计
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Süreç şu şekilde gelişir:
· Şema oluşturma: Şema, önceden tanımlanmış bir veri yapısı sağlar. İnsanlar bunu kendi özel kullanım durumlarına uyacak şekilde uyarlayabilir.
· Şemaya dayalı modüller oluşturun: Modül olarak kaydedilen akıllı sözleşme bayt kodunu alır ve şema kimliğini seçer ve veriler kayıt defterinde saklanır.
· Modülün onayını alın: Kanıtlayıcı/denetçi, mimariye dayalı olarak modülün kanıtını sağlayabilir. Bu onaylar, benzersiz bir tanımlayıcı (UID) ve bağlantı için kullanılan diğer onaylara referanslar içerebilir. Zincirler arasında yayılabilir ve hedef zincirin belirli eşikleri karşıladığını doğrulayabilirler.
· Bir çözümleyici ile karmaşık mantık uygulayın: Ayrıştırıcı (isteğe bağlı) devreye girer. Modül oluşturma, kanıtlama oluşturma ve iptal sırasında çağrılabilirler. Bu ayrıştırıcılar, geliştiricilerin kanıt yapılarını korurken karmaşık ve çeşitli mantığı entegre etmesine olanak tanır.
Kullanıcı dostu sorgu erişimi: Sorgu, kullanıcıların ön uçtan güvenlik bilgilerine erişmesi için bir yol sağlar.
Model henüz erken aşamalarında olsa da, merkezi olmayan ve işbirlikçi bir şekilde standartlar oluşturma potansiyeline sahiptir. Kayıt defteri, geliştiricilerin modüllerini kaydetmesine, denetçilerin güvenliklerini doğrulamasına, cüzdanların entegre olmasına ve kullanıcıların modülleri kolayca bulmasına ve doğrulama bilgilerini doğrulamasına olanak tanır. Gelecekteki birkaç kullanım şunlar olabilir:
· Onaylayıcı: Safe gibi güvenilir bir varlık, dahili modüller için bir kanıtlayıcı olarak Rhinestone ile çalışabilir. Aynı zamanda, bağımsız sertifikalandırıcılar da katılabilir.
· Modül geliştiricisi: Açık bir pazarın oluşmasıyla birlikte, modül geliştiricilerin çalışmalarından bir kayıt defteri aracılığıyla para kazanmaları mümkündür.
· Kullanıcılar: Cüzdan veya dApp gibi kullanıcı dostu bir arayüz aracılığıyla katılmak, kullanıcıların modül bilgilerini kontrol etmesine ve farklı kanıtlayıcılara güven vermesine olanak tanır.
"Modül kayıt defteri" kavramı, eklenti ve modül geliştiricilerinin para kazanması için yollar açar. Bir "modül pazarının" önünü daha da açabilir. Bazı yönler Safe ekibi tarafından denetlenebilirken, diğerleri herkesi katkıda bulunmaya davet eden ve şeffaf bir denetim izi sağlayan merkezi olmayan bir pazar yeri olarak tezahür edebilir. Bunu dahil etmek, satıcıya bağımlılığı önler ve daha geniş bir kitleye hitap eden gelişmiş bir kullanıcı deneyimi ekleyerek EVM'nin genişlemesini destekler.
Bu yöntemler bireysel modüllerin güvenliğini garanti ederken, daha geniş güvenlik söz konusu olduğunda akıllı sözleşme hesapları kusursuz değildir. Uyumluluk modülleriyle birleştirmek ve depolama çakışmaları olmadığını kanıtlamak zor olabilir, bu da bu tür sorunları ele almada cüzdanların veya AA altyapısının önemini vurgular.
Özet
Modüler bir akıllı sözleşme hesap yığınından yararlanarak, cüzdan sağlayıcıları ve dApp'ler teknik bakımın karmaşıklığından kurtulabilir. Aynı zamanda, harici modül geliştiricileri, kişiselleştirilmiş profesyonel hizmetler sunma fırsatına sahiptir. Bununla birlikte, ele alınması gereken zorluklar arasında esneklik ve güvenlik arasında bir denge kurmak, modüler standartları zorlamak ve kullanıcıların akıllı hesaplarını kolayca yükseltmelerine ve değiştirmelerine olanak tanıyan standartlaştırılmış arayüzlerin uygulanması yer alır.
Ek olarak, Modüler Akıllı Sözleşme Hesapları (SCA'lar), benimseme bulmacasının yalnızca küçük bir parçasıdır. SCA'nın tam potansiyelini gerçekleştirmek için, sağlam paketleyici altyapısı ve eşler arası bellek havuzları, daha uygun maliyetli ve uygulanabilir bir SCA imzalama mekanizması, zincirler arası SCA senkronizasyonu ve yönetim mekanizmaları ve kullanıcı dostu arayüzlerin geliştirilmesi gibi ek protokol katmanı desteği sağlamak için Katman 2 çözümlerine ihtiyaç vardır.
Gelecekte, SCA'nın daha fazla benimsenmesi olacak, ancak aynı zamanda bazı ilginç soruları da gündeme getirecek: SCA emir akışı yeterince karlı hale geldiğinde, geleneksel madenci çıkarılabilir değer (MEV) mekanizmaları, paketleyiciler oluşturmak ve değer elde etmek için alana nasıl girecek ve altyapı olgunlaştığında hesap soyutlaması (AA) "amaca dayalı" işlemler için nasıl temel katman görevi görecek?
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 mimarilerine ve zorluklarına derinlemesine bir bakış
作者:Rui,SevenX Ventures'ın Yatırımcısı
编译:Luccy,Joyce,BlockBeats
SevenX Ventures >'da bir yatırımcı olan Rui, SCA'yı benimsemenin önündeki en önemli beş zorluğu (ayı piyasası etkisi, geçiş zorluğu, imza sorunları, yüksek gaz maliyetleri ve mühendislik zorlukları) belirledi ve bunları daha ayrıntılı olarak tartıştı. Ek olarak, modüler akıllı sözleşme hesaplarının mimarisinin analizi, modüler SCA'nın benimseme zorluklarının yalnızca küçük bir parçası olduğuna işaret ediyor.
Harici olarak sahip olunan hesaplardan (EOA) akıllı sözleşme hesaplarına (SCA'lar) geçiş ivme kazanıyor ve Vitalik de dahil olmak üzere birçok çekirdek girişimci tarafından destekleniyor. Buna rağmen, SCA'nın benimsenmesi EOA'nınki kadar yaygın olmamıştır. Temel konular arasında ayı piyasasının etkisi, EOA'yı SCA'ya taşımanın zorluğu, imza sorunları, yüksek gaz maliyetleri ve en önemlisi geliştirme zorlukları yer alıyor.
Hesap Soyutlama'nın (AA) en önemli avantajı, kod kullanarak işlevselliği özelleştirme yeteneğidir. Bununla birlikte, AA işlevselliğinin birlikte çalışamaması, bu parçalanma AA entegrasyonunu engellediğinden ve satıcıya bağımlılığı güçlendirdiğinden büyük bir zorluk teşkil etmektedir. Ayrıca, yükseltilebilir ve birleştirilebilir olurken güvenliği sağlamak da önemli bir zorluktur.
Modüler hesap soyutlamasının ortaya çıkışı, akıllı hesapları özel özelliklerinden ayıran yenilikçi bir yaklaşım olan AA trendinde bir niş. Amaç, birden fazla özelliğe, güvenliğe ve sorunsuz entegrasyona sahip cüzdanlar geliştirmek için modüler bir yapı oluşturmaktı. Gelecekte, modüler hesap soyutlama, ücretsiz bir akıllı sözleşme hesabı "uygulama mağazasını" etkinleştirecek ve cüzdanların ve dApp'lerin özellikler oluşturmak için çok fazla çaba harcamak yerine kullanıcı deneyimini iyileştirmeye odaklanmasına olanak tanıyacak.
Kısa Hesap Soyutlama (AA)
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
Geleneksel EOA, insanların blok zincirine maruz kalmasına tohum ifadeleri, gaz ücretleri, zincirler arası işlemler ve çoklu işlemler gibi birçok zorluk getirir.
Hesap soyutlama, programlanabilir doğrulama ve kullanıma izin vermek için akıllı sözleşme hesaplarından yararlanır. Bu, kullanıcıların her işlemi imzalamak ve yayınlamak zorunda kalmadan bir dizi işlemi bir kerede onaylayabilecekleri anlamına gelir. Hesap soyutlama, iyileştirilmiş kullanıcı deneyimi (örneğin, gaz soyutlaması ve oturum anahtarları), azaltılmış maliyetler (örneğin, toplu işlemler) ve gelişmiş güvenlik (örneğin, sosyal kurtarma, çoklu imza) gibi daha fazla özelliği de etkinleştirebilir. Şu anda, hesapları soyutlamanın iki yolu vardır:
· Protokol katmanı: Bazı protokoller yerel olarak yerel hesap soyutlama desteği sağlar, ZKSync işlemleri AA'yı desteklemek için tek bir bellek havuzu ve işlem akışı kullanır, hem EOA hem de SCA'dan aynı süreci takip ederken, Starknet EOA'yı kaldırmıştır, tüm hesaplar SCA'dır ve Argent gibi yerel akıllı sözleşme cüzdanlarına sahiptirler.
· Sözleşme katmanı: Ethereum ve benzeri L2'ler için ERC4337, konsensüs katmanını değiştirmeden AA'yı desteklemek için ayrı bir mempool tanıttı. Stackup, Alchemy, Etherspot, Biconomy, Candide ve Plimico gibi yerler paketleyici altyapısı oluştururken, Safe, Zerodev, Etherspot ve Biconomy gibi şeyler paketleyiciler ve SDK'lar oluşturuyor.
SCA'yı benimseme ikilemi
Hesap soyutlama (AA) konusu 2015'ten beri tartışılmaktadır ve bu yıl ERC 4337 ile daha da ön plana çıkarılmıştır. Bununla birlikte, konuşlandırılan akıllı sözleşme hesaplarının sayısı hala EOA kadar düşük değil.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Bu ikilemi inceleyelim:
AA'nın sorunsuz oturum açma ve gaz çıkarma gibi avantajlarına rağmen, tüm kullanıcıların eğitimli EOA kullanıcıları olduğu ve çok fazla yeni kullanıcının olmadığı mevcut ayı piyasasında, dApp'lerin ve cüzdanların SCA'yı benimsemesi için herhangi bir teşvik yoktur. Buna rağmen, önde gelen dApp'lerden bazıları, AA sistemlerini ve gazsız çözümlerini tanıtarak yalnızca bir ayda yaklaşık 360.000 UserOps (AA işlemi) sağlayan Cyberconnect gibi AA'yı kademeli olarak benimsiyor.
Halihazırda kullanıcı ve varlık biriktirmiş cüzdanlar ve uygulamalar için, varlıkları güvenli ve rahat bir şekilde taşımak bir zorluk olmaya devam ediyor. Ancak, EIP-7377 gibi bir şema, EOA'nın tek seferlik bir geçiş işlemi başlatmasına izin verir.
Akıllı sözleşmenin kendisi, EOA gibi özel bir anahtara sahip olmadığı için mesajları imzalayamaz. ERC1271 gibi girişimler bunu mümkün kılar, ancak mesaj imzalama ilk işleme kadar çalışmaz ve bu da karşı olgularla dağıtılan cüzdanlar için bir zorluk teşkil eder. Ambire tarafından önerilen ERC-6492, ERC-1271'in geriye dönük uyumlu halefidir ve önceki sorunu çözebilir.
Standart EOA'ya kıyasla SCA'yı dağıtma, simüle etme ve yürütme maliyetinin daha yüksek olması da benimsemenin önünde bir engeldir. Ancak, hesap oluşturmayı kullanıcı eylemlerinden ayırmak, bir hesapla ilişkili "tuzu" ortadan kaldırmak ve daha fazlası gibi bazı testler yapılmıştır.
ERC-4337 ekibi, geliştiriciler için temel bir uygulama sağlayan bir eth-infinitism deposu oluşturdu. Bununla birlikte, geliştiriciler farklı kullanım durumları için daha ayrıntılı ve belirli özelliklere ölçeklendikçe, entegrasyon ve kod çözme daha fazla zorlukla karşı karşıya kalmaktadır. Bu yazıda, mühendislik zorluklarını inceleyeceğiz.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
Modüler akıllı sözleşme hesaplarıyla mühendislik zorluklarını çözün
Mühendislik zorlukları üç açıdan daha ayrıntılı olarak açıklanabilir: parçalanma, güvenlik ve yükseltilebilirlik.
· Parçalanma: Özellikler artık belirli bir SCA veya bağımsız bir eklenti sistemi aracılığıyla çeşitli şekillerde etkinleştirilebilir. Her platform ve hizmet sağlayıcı kendi standartlarını takip ederek geliştiricilerin hangi platformları ve hizmet sağlayıcıları destekleyeceklerine karar vermelerini ister. Bu, potansiyel platform (satıcı) kilitlenmesine veya gereksiz çalışmaya yol açabilir.
· Güvenlik: Hesapların ve işlevlerin birbirinden ayrılması esneklik avantajı sağlarken, güvenlik sorunlarını daha ciddi hale getirebilir. Tüm özellikler birlikte gözden geçirilebileceğinden, bağımsız bir değerlendirmenin olmaması hesap güvenlik açığı riskini artırabilir.
· Yükseltilebilirlik: Hesabınız büyüdükçe, özellik ekleme, değiştirme veya kaldırma olanağını korumak önemlidir ve mevcut özellikleri yeniden dağıtan her güncelleştirme karmaşıklığa neden olur.
Bu sorunları çözmek için, güvenli ve verimli yükseltmeler sağlamak için yükseltilebilir sözleşmelere, genel geliştirme verimliliğini artırmak için yeniden kullanılabilir çekirdeklere ve farklı ön uçlar arasında sorunsuz bir geçiş sağlamak için standartlaştırılmış arayüzlere ihtiyacımız var.
Bu terimler ortak bir kavram üzerinde birleşir: modüler bir hesap soyutlama mimarisi (Modüler AA) oluşturmak.
Modüler hesap soyutlama, kullanıcılara özelleştirilmiş hizmetler sağlamak ve geliştiricilerin minimum kısıtlamayla işlevselliği sorunsuz bir şekilde geliştirmelerini sağlamak için akıllı hesapların modülerleştirilmesini öngören daha geniş AA geliştirmesinin bir alt bölümüdür.
Bununla birlikte, herhangi bir sektörde yeni standartlar oluşturmak ve teşvik etmek büyük bir zorluktur. Herkes aynı standardı kabul edene kadar, başlangıç aşamasında birçok farklı çözüm ortaya çıkabilir. 4337 SDK, cüzdanlar, altyapı ekipleri veya protokol katmanı tasarımcıları olsun, hesap soyutlamasını iyileştirmek ve teşvik etmek için çalışanların bu süreci hızlandırmak için birlikte çalıştığını görmek cesaret verici.
Modüler yapı: ana hesaplar ve modüller
Hesap, işlevi uygulamak için modülü nasıl çağırır?
Temsilci çağrısı ve proxy sözleşmesi
Harici ve yetkilendirilmiş aramalar:
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
Temsilci çağrıları hakkında
"Yetkilendirilmiş çağrı", "çağrı"ya benzer olsa da, hedef sözleşme bağlamında değil, çağrı sözleşmesinin mevcut durumu bağlamında yürütülür. Bu, hedef sözleşme tarafından yapılan herhangi bir durum değişikliğinin, arayan sözleşmenin depolanmasını değiştireceği anlamına gelir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Proxy sözleşmeleri ve temsilci çağrıları
**Birleştirilebilir ve yükseltilebilir bir yapı elde etmek için, temel bir "acentelik sözleşmesi" kavramının tanıtılması gerekir. **
Proxy sözleşmesi: Normal bir sözleşme mantığını ve durumunu depolar ve dağıtımdan sonra güncelleştirilemez. Proxy sözleşmesi, temsilci çağrısı kullanılarak başka bir sözleşmeye dağıtılır. İşlevi, proxy sözleşmesinin geçerli durumunda yürütmek için başvuruya göre uygulayın.
Kullanım örneği: Proxy sözleşmesi aynı kalırken, aracının arkasında yeni bir uygulama dağıtabilirsiniz. Proxy sözleşmeleri yükseltilebilir ve halka açık blok zincirlerinde dağıtılması ve sürdürülmesi daha ucuzdur.
Güvenli Mimari! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Güvenli mimari
Güvenli Olan: Safe, savaşta test edilmiş güvenlik ve esneklik sağlamak için tasarlanmış önde gelen modüler akıllı hesap altyapısıdır ve geliştiricilerin çeşitli uygulamalar ve cüzdanlar oluşturmasına olanak tanır. Birçok ekip, Safe'in üzerine (veya Safe'den ilham alarak) uygulamalar geliştiriyor. Örneğin, Biconomy, akıllı sözleşme hesabını başlattığında Safe'i yerel 4337 ve 1/1 multisig ile genişletti. 164.000'den fazla sözleşmenin dağıtımına tanık olan ve 30,7 milyar doların üzerinde değere kilitlenen Safe, şüphesiz kendi alanında liderdir.
Safe'in yapısı bir güvenli hesap sözleşmesi, bir tekil sözleşme ve bir modül sözleşmesi içerir.
Proxy sözleşmesi: Durum bilgisi olan
Temsilci olarak atanan çağrı tekil bir sözleşme olduğundan güvenli hesap bir proxy sözleşmesidir. Bir güvenlik hesabı, sahip, eşik ve uygulama adresinin tümünün aracı olarak ayarlandığı ve durumlarının bunlara göre tanımlandığı değişkenler içerir.
单例合约(singleton contract):Integration Hub(无状态)
Tekil sözleşme, Güvenli hesaplara hizmet eder ve Eklenti, Kanca, İşlev İşleyici ve İmza Doğrulayıcı dahil olmak üzere farklı modül sözleşme entegrasyonlarını tanımlar.
Modüller: Özel mantık ve işlevsellik
Modül sözleşmeleri güçlüdür. Modüler türler olarak eklentiler, ödeme akışları, kurtarma mekanizmaları ve oturum anahtarları gibi farklı işlevleri tanımlayabilir ve zincir dışı verileri getirerek Web2 ile Web3 arasında bir köprü görevi görebilir. Güvenlik görevlileri olarak Hooks ve Function Handlers gibi diğer modüller herhangi bir komuta yanıt verebilir.
Safe'in kullanılmaya başlanmasından bu yana değişen değişiklikler:
Yükseltilebilir sözleşmeler: Yeni bir eklenti piyasaya sürüldüğünde, yeni bir singleton'un dağıtılması gerekir. Kullanıcı, Safe'i istenen tekil sürüme yükseltme özerkliğini korur.
Birleştirilebilir, yeniden kullanılabilir modüller: Eklentilerin modüler yapısı, geliştiricilerin özellikleri bağımsız olarak geliştirmesine olanak tanır. Bu eklentileri kullanım durumlarına göre seçmekte ve birleştirmekte özgürdürler, bu da son derece özelleştirilebilir bir yaklaşımla sonuçlanır.
ERC-2535 Elmas 代理
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
ERC2535 Hakkında, Elmas Ajan:
ERC2535 standartlaştırılmış Diamond modeli, neredeyse hiçbir boyut sınırlaması olmaksızın dağıtımdan sonra yükseltilebilen/ölçeklendirilebilen modüler bir akıllı sözleşme sistemidir. Şu anda Zerodev'in Kernel'i ve Soul Wallet'ın deneyleri gibi birçok ekip Diamond yapısından ilham almış durumda.
Pırlanta Yapısı Nedir:**
Diamond Sözleşmesi: Birincil Vekil Sözleşmesi (Stateful) Diamond, bir işlevi uygulamasından çağırmak için yetkilendirilmiş bir çağırma yöntemi kullanan bir vekil sözleşmesidir.
Modül/Eklenti/Faset Sözleşmesi: Özel Mantık ve İşlevsellik (Durumsuz) Bir modül veya sözde Faset, işlevselliğini bir veya daha fazla Elmas'a dağıtabilen durum bilgisi olmayan bir sözleşmedir. Bunlar, içsel işlevleri, kitaplıkları ve durum değişkenlerini paylaşabilen ayrı, bağımsız sözleşmelerdir.
Elmas ile yapılan değişiklikler:
Yükseltilebilir Sözleşmeler: Diamond, farklı eklentileri izole etmek ve bunları birbirine bağlamak, aralarında veri paylaşmak ve ayrıca doğrudan diamondCut özelliğini kullanarak herhangi bir eklentiyi eklemek/değiştirmek/kaldırmak için sistematik bir yol sağlar. Zamanla, Diamond'a eklenebilecek eklenti sayısında bir sınırlama olmayacaktır.
Modüler ve yeniden kullanılabilir eklentiler: Dağıtılan eklentiler herhangi bir sayıda Elmas tarafından kullanılabilir ve bu da dağıtım maliyetlerini önemli ölçüde azaltır.
Güvenli Akıllı Hesap ile Diamond yöntemi arasındaki fark:
Safe ve Diamond mimarileri arasında, her ikisi de yükseltilebilirlik ve modülerlik için temel proxy sözleşmelerine ve referans mantıksal sözleşmelerine dayanan pek çok benzerlik vardır.
İkisi arasındaki temel fark, mantıksal sözleşmelerin ele alınmasıdır. Özellikle:
· Esneklik: Yeni bir eklenti etkinleştirildiğinde, Safe'in proxy'sindeki değişiklikleri uygulamak için tekil sözleşmesini yeniden dağıtması gerekir. Buna karşılık, Diamond bunu doğrudan vekil sözleşmesindeki diamondCut işlevi aracılığıyla gerçekleştirir. Yaklaşımdaki farklılık, Safe'in daha yüksek bir kontrol derecesini koruduğu anlamına gelirken, Diamond gelişmiş esneklik ve modülerlik sunar.
· Güvenli: Şu anda her iki yapıda da kullanılan, harici kodun ana sözleşmenin depolanmasını manipüle etmesine izin verir. Güvenli mimaride, temsilci çağrıları tek bir mantıksal sözleşmeye işaret ederken, Diamond birden çok modül sözleşmesi-eklentisi arasında temsilci çağrıları kullanır. Sonuç olarak, kötü amaçlı bir eklentinin başka bir eklentinin üzerine yazması, depolama çakışmaları riskini ortaya çıkarması ve proxy'nin bütünlüğünü tehlikeye atması mümkündür.
· Maliyet: Diamond yaklaşımında esneklik ve güvenlik bir araya gelir. Bu, maliyeti artırır ve her yeni eklenti eklendiğinde tamamen denetlenmesi gerekir. Önemli olan, bu eklentilerin birbirlerinin işlevselliğine müdahale etmemesini sağlamaktır, bu da özellikle yüksek güvenlik standartlarını korumak için mücadele eden küçük ve orta ölçekli işletmeler için zorlu bir amaçtır.
"Güvenli Akıllı Hesap Yöntemi" ve "Elmas Yöntemi", aracıları ve modülleri içeren farklı yapılara örnektir. Esneklik ve güvenliğin dengelenmesi kritik öneme sahiptir ve bu iki yaklaşım gelecekte gelişmeye ve birbirini tamamlamaya devam edecektir.
Modül Sırası: Doğrulayıcı, Yürütücü ve Kanca
Alchemy ekibinden ERC-4337 için özel olarak uyarlanmış, Diamond'dan ilham alan bir standart olan ERC6900'i tanıtarak bunu daha fazla tartışalım. Ortak bir arayüz sağlayarak akıllı hesap modülerliğinin zorluklarını çözer ve eklenti ile cüzdan geliştiricileri arasındaki çalışmayı koordine eder.
AA'nın işlem süreci söz konusu olduğunda, üç ana süreç vardır: doğrulama, yürütme ve ilişkilendirme. Daha önce tartıştığımız gibi, bu adımların tümü proxy hesabı çağrı modülü kullanılarak yönetilebilir. Farklı projeler farklı isimler kullanabilse de, benzerliğin altında yatan mantığı kavramak önemlidir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
Farklı tasarımlarda fonksiyonun adı
Doğrulayıcı: Hesabı arayanın gerçekliğini ve izinlerini sağlar.
Yürütme (UTOR): Hesabın izin verdiği herhangi bir özel mantığı yürütün.
Kanca: Başka bir işlevden önce veya sonra çalışan bir modül görevi görür. Durumu değiştirebilir veya tüm aramayı geri alabilir.
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
Modülleri farklı mantıklara göre ayırmak önemlidir. Standartlaştırılmış yaklaşım, akıllı sözleşme hesapları için doğrulama, yürütme ve ilişkilendirme işlevlerinin nasıl yazılacağını belirtmelidir. İster Güvenli ister ERC6900 olsun, standardizasyon, belirli uygulamalara veya ekosistemlere özgü benzersiz geliştirme çabalarına olan ihtiyacı azaltmaya yardımcı olur ve satıcıya bağımlılığı önler.
Modül keşfi ve güvenliği
Modüller açık bir şekilde nasıl bulunur ve doğrulanır: Geliştirilmekte olan bir çözüm, kullanıcıların "kayıt defteri" olarak adlandırılabilecek doğrulanabilir modülleri keşfetmesine olanak tanıyan bir alan oluşturmayı içerir. Kayıt defteri bir "uygulama mağazası" gibi işlev görür ve basitleştirilmiş ancak gelişen modüler bir pazarı teşvik etmeyi amaçlar.
Safe{Core} 协议
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
Safe{Core} protokolü, iyi tanımlanmış standartlar ve kurallar aracılığıyla güçlü güvenliği korurken çok çeşitli satıcılar ve geliştiriciler için erişilebilirliği artırmak üzere tasarlanmış akıllı sözleşme hesapları için açık kaynaklı, birlikte çalışabilir bir protokoldür.
· Hesaplar: Safe{Core} protokolünde, hesap kavramı esnektir ve belirli bir uygulamaya bağlı değildir. Bu, farklı hesap hizmeti sağlayıcılarının dahil olmasına olanak tanır.
· Yönetici: Yönetici, hesaplar, kayıtlar ve modüller arasında bir koordinatör görevi görür. Ayrıca bir lisanslama katmanı olarak güvenlikle de ilgilenir.
· Kayıt defteri: Kayıt defteri, güvenlik özniteliklerini tanımlar ve bulunabilirlik ve güvenlik için açık bir "uygulama mağazası" ortamı oluşturmak için ERC6900 gibi modül standartlarını zorlar.
· 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ürlerine sahiptir. Geliştiriciler, belirlenen kriterleri karşıladıkları sürece dahil olabilirler.
Rhinestone 设计
! [Modüler akıllı sözleşme hesap mimarisine ve zorluklarına derinlemesine bir bakış] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
Süreç şu şekilde gelişir:
· Şema oluşturma: Şema, önceden tanımlanmış bir veri yapısı sağlar. İnsanlar bunu kendi özel kullanım durumlarına uyacak şekilde uyarlayabilir.
· Şemaya dayalı modüller oluşturun: Modül olarak kaydedilen akıllı sözleşme bayt kodunu alır ve şema kimliğini seçer ve veriler kayıt defterinde saklanır.
· Modülün onayını alın: Kanıtlayıcı/denetçi, mimariye dayalı olarak modülün kanıtını sağlayabilir. Bu onaylar, benzersiz bir tanımlayıcı (UID) ve bağlantı için kullanılan diğer onaylara referanslar içerebilir. Zincirler arasında yayılabilir ve hedef zincirin belirli eşikleri karşıladığını doğrulayabilirler.
· Bir çözümleyici ile karmaşık mantık uygulayın: Ayrıştırıcı (isteğe bağlı) devreye girer. Modül oluşturma, kanıtlama oluşturma ve iptal sırasında çağrılabilirler. Bu ayrıştırıcılar, geliştiricilerin kanıt yapılarını korurken karmaşık ve çeşitli mantığı entegre etmesine olanak tanır.
Kullanıcı dostu sorgu erişimi: Sorgu, kullanıcıların ön uçtan güvenlik bilgilerine erişmesi için bir yol sağlar.
Model henüz erken aşamalarında olsa da, merkezi olmayan ve işbirlikçi bir şekilde standartlar oluşturma potansiyeline sahiptir. Kayıt defteri, geliştiricilerin modüllerini kaydetmesine, denetçilerin güvenliklerini doğrulamasına, cüzdanların entegre olmasına ve kullanıcıların modülleri kolayca bulmasına ve doğrulama bilgilerini doğrulamasına olanak tanır. Gelecekteki birkaç kullanım şunlar olabilir:
· Onaylayıcı: Safe gibi güvenilir bir varlık, dahili modüller için bir kanıtlayıcı olarak Rhinestone ile çalışabilir. Aynı zamanda, bağımsız sertifikalandırıcılar da katılabilir.
· Modül geliştiricisi: Açık bir pazarın oluşmasıyla birlikte, modül geliştiricilerin çalışmalarından bir kayıt defteri aracılığıyla para kazanmaları mümkündür.
· Kullanıcılar: Cüzdan veya dApp gibi kullanıcı dostu bir arayüz aracılığıyla katılmak, kullanıcıların modül bilgilerini kontrol etmesine ve farklı kanıtlayıcılara güven vermesine olanak tanır.
"Modül kayıt defteri" kavramı, eklenti ve modül geliştiricilerinin para kazanması için yollar açar. Bir "modül pazarının" önünü daha da açabilir. Bazı yönler Safe ekibi tarafından denetlenebilirken, diğerleri herkesi katkıda bulunmaya davet eden ve şeffaf bir denetim izi sağlayan merkezi olmayan bir pazar yeri olarak tezahür edebilir. Bunu dahil etmek, satıcıya bağımlılığı önler ve daha geniş bir kitleye hitap eden gelişmiş bir kullanıcı deneyimi ekleyerek EVM'nin genişlemesini destekler.
Bu yöntemler bireysel modüllerin güvenliğini garanti ederken, daha geniş güvenlik söz konusu olduğunda akıllı sözleşme hesapları kusursuz değildir. Uyumluluk modülleriyle birleştirmek ve depolama çakışmaları olmadığını kanıtlamak zor olabilir, bu da bu tür sorunları ele almada cüzdanların veya AA altyapısının önemini vurgular.
Özet
Modüler bir akıllı sözleşme hesap yığınından yararlanarak, cüzdan sağlayıcıları ve dApp'ler teknik bakımın karmaşıklığından kurtulabilir. Aynı zamanda, harici modül geliştiricileri, kişiselleştirilmiş profesyonel hizmetler sunma fırsatına sahiptir. Bununla birlikte, ele alınması gereken zorluklar arasında esneklik ve güvenlik arasında bir denge kurmak, modüler standartları zorlamak ve kullanıcıların akıllı hesaplarını kolayca yükseltmelerine ve değiştirmelerine olanak tanıyan standartlaştırılmış arayüzlerin uygulanması yer alır.
Ek olarak, Modüler Akıllı Sözleşme Hesapları (SCA'lar), benimseme bulmacasının yalnızca küçük bir parçasıdır. SCA'nın tam potansiyelini gerçekleştirmek için, sağlam paketleyici altyapısı ve eşler arası bellek havuzları, daha uygun maliyetli ve uygulanabilir bir SCA imzalama mekanizması, zincirler arası SCA senkronizasyonu ve yönetim mekanizmaları ve kullanıcı dostu arayüzlerin geliştirilmesi gibi ek protokol katmanı desteği sağlamak için Katman 2 çözümlerine ihtiyaç vardır.
Gelecekte, SCA'nın daha fazla benimsenmesi olacak, ancak aynı zamanda bazı ilginç soruları da gündeme getirecek: SCA emir akışı yeterince karlı hale geldiğinde, geleneksel madenci çıkarılabilir değer (MEV) mekanizmaları, paketleyiciler oluşturmak ve değer elde etmek için alana nasıl girecek ve altyapı olgunlaştığında hesap soyutlaması (AA) "amaca dayalı" işlemler için nasıl temel katman görevi görecek?