Modüler Akıllı Sözleşme Hesabı Mimarisi ve Zorluklar

Giriş

Harici Sahipli Hesaplardan (EOA) Akıllı Sözleşme Hesaplarına (SCA) geçiş ivme kazanıyor ve Vitalik'in kendisi de dahil olmak üzere pek çok meraklı tarafından benimseniyor. Heyecana rağmen SCA'nın benimsenmesi EOA'lar kadar yaygın değil. Bunların arasında en önemlileri ayı piyasalarının yarattığı zorluklar, göç endişesi, imza sorunları, genel yakıt giderleri ve en önemlisi mühendislik zorluklarıdır.

Hesap Soyutlamalarının (AA) en önemli avantajı, işlevselliği özelleştirmek için kod kullanma yeteneğidir. Bununla birlikte, önemli bir mühendislik sorunu, AA işlevlerinin birlikte çalışamamasıdır ve parçalanma, entegrasyonu engellemekte ve satıcıya bağımlılığa kapı açmaktadır. Ek olarak, özellikleri aynı anda yükseltirken ve oluştururken güvenliği sağlamak karmaşık olabilir.

Daha geniş AA hareketinin bir alt kümesi olarak Modüler Hesap Soyutlamasına girin, bu yenilikçi yaklaşım akıllı hesapları özel işlevlerinden ayırabilir. 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, akıllı sözleşme hesapları için, cüzdanları ve dApp'leri geliştirme özelliklerinden arındıran ancak kullanıcı deneyimine odaklanan ücretsiz bir "uygulama mağazası" gerçekleştirebilir.

Bu makaleyi okuduktan sonra okuyucular aşağıdaki konularda bilgi sahibi olacak:

1. Modüler Hesap Soyutlaması Nedir?
2. Hesap modüllerle nasıl etkileşime giriyor?
3. Modülleri çağırma sırası nedir?
4. Modülleri açık bir şekilde bulma ve doğrulama

AA'ya Kısa Bir Bakış

SCA Manzarası

Geleneksel EOA, tohum cümlesi, gas, zincirler arası ve çoklu işlemler gibi birçok zorluğu beraberinde getirir. Hiçbir zaman karmaşıklık yaratmayı amaçlamadık ama aslında blockchain kitleler için kolay bir oyun değil.

Hesap Soyutlama, kullanıcının her birini imzalayıp yayınlamak yerine bir dizi işlemi tek seferde onaylayabildiği ve daha birçok özelliği uygulayabildiği, programlanabilir doğrulama ve yürütmeye olanak tanıyan akıllı sözleşme hesabından yararlanır. Kullanıcı deneyimine faydalar sağlar (örn. gaz soyutlaması ve oturum anahtarları), maliyet (ör. toplu işlem) ve güvenlik (örn. sosyal iyileşme, çoklu imza). Şu anda hesap soyutlamayı gerçekleştirmenin iki yolu vardır:

1. Protokol katmanı: Bazı protokollerin kendileri yerel hesap soyutlama desteği sağlar; ZKsync işlemleri, ister EOA'dan ister AA'yı desteklemek için tek bir bellek havuzu ve işlem akışı kullanan SCA'dan gelsin aynı akışı izler ve Starknet , EOA'yı kaldırmıştır ve tüm hesaplar SCA'dır ve bunlar Argent gibi yerel akıllı sözleşme cüzdanları.
2. Sözleşme katmanı: Ethereum ve eşdeğer L2'ler için ERC4337 , konsensüs katmanını değiştirmeden AA'yı desteklemek amacıyla işlemler için ayrı bir giriş noktası sunar. Stackup, Alchemy, Etherspot, Biconomy, Candide ve Plimico gibi projeler paketleyici altyapısı oluşturuyor ve Safe, Zerodev, Etherspot ve Biconomy gibi daha pek çok proje yığın ve SDK oluşturuyor.

👉 AA veya ERC4337'ye aşina değilseniz SevenX'in önceki araştırmasına buradan göz atın.

SCA'nın Benimsenmesinin İkilemi

Hesap Soyutlama (AA) konusu 2015'ten beri tartışılıyor ve bu yıl ERC4337 tarafından daha da ilgi odağı haline getirildi. Ancak konuşlandırılan akıllı sözleşme hesaplarının sayısı, EOA'larla karşılaştırıldığında hâlâ sönük kalıyor.

Bu ikilemi biraz daha açalım:

1. Ayı Piyasası Etkisi:
   AA kusursuz oturum açma ve gas soyutlama gibi avantajlar sunsa da, hakim ayı piyasası öncelikle yenilerden ziyade eğitimli EOA kullanıcılarından oluşuyor, dolayısıyla dApp'ler ve cüzdanlar için herhangi bir teşvik yok. Bunu söylesek bile, Cyberconnect gibi önde gelen uygulamalar AA sistemlerini ve gazsız çözümlerini tanıtarak yalnızca ayda yaklaşık 360.000 UserOps (AA işlemi) gerçekleştirdi.
2. Göç Engelleri:
   Kullanıcıları biriktiren ve varlıkları EOA'larda depolayan cüzdanlar ve uygulamalar için, varlıkların güvenli ve rahat bir şekilde taşınması hala bir zorluk olmaya devam ediyor. Bununla birlikte, EIP-7377 gibi girişimler, EOA'ların tek seferlik bir geçiş işlemi başlatmasına izin veriyor.
3. İmza Sorunu:
   Akıllı sözleşmenin kendisi doğal olarak mesajları imzalayamaz çünkü EOA'lar gibi özel bir anahtara sahip değildir. ERC1271 gibi çabalar bunu mümkün kılıyor ancak mesaj imzalama ilk işleme kadar işe yaramayacak, bu da karşı olgusal dağıtım kullanan cüzdanlar için bir zorluk teşkil ediyor. Ambire tarafından önerilen ERC-6492, önceki sorunu potansiyel olarak çözen ERC-1271'in geriye dönük uyumlu halefidir.
4. Gaz Giderleri:
   SCA'ları dağıtmak, simüle etmek ve yürütmek, standart EOA'lara kıyasla daha yüksek maliyetlere neden olur. Bu da evlat edinme konusunda caydırıcı oluyor. Ancak hesap oluşturmayı kullanıcı işlemlerinden ayırmak, hesap tuzunu ortadan kaldırmak ve varlık kontrolleri gibi çeşitli testler yapılmış olup bu maliyetlerin düşürülmesi düşünülmektedir.
5. Mühendislik Zorlukları:
   ERC-4337 ekibi, geliştiricilere temel bir uygulama sağlamak için et-infinitism deposunu kurdu. Ancak farklı kullanım durumları için daha incelikli veya spesifik işlevlere yöneldikçe entegrasyon ve kod çözme zorlu hale geliyor.

Bu yazıda 5 numaralı soruna değineceğiz: mühendislik zorlukları.

🤔️

Mühendislik Zorluklarını Çözecek Modüler Akıllı Sözleşme Hesabı

Mühendislik zorluklarını daha ayrıntılı olarak açıklamak gerekirse:

1. Parçalanma:
   Özellikler artık yerel olarak belirli SCA'lar veya bağımsız eklenti sistemleri aracılığıyla çeşitli şekillerde etkinleştiriliyor. Her biri kendi standardını takip ederek geliştiricileri hangi platformları destekleyeceğine karar vermeye zorluyor. Bu, potansiyel platform kilitlenmelerine veya gereksiz çabalara yol açar.
2. Güvenlik:
   Hesaplar ve özellikler arasındaki esneklik avantajlar sunsa da güvenlik endişelerini artırabilir. Özellikler toplu olarak denetlenebilir ancak bağımsız değerlendirmelerin olmaması, hesaptaki güvenlik açıkları riskini artırabilir.
3. Yükseltilebilirlik:
   Özellikler geliştikçe işlevsellik ekleme, değiştirme veya kaldırma kapasitesini korumak önemlidir. Her güncellemede mevcut özelliklerin yeniden dağıtılması karmaşıklıklara neden olur.

Bu sularda ilerlemek için, güvenli ve verimli yükseltmeler sağlayan 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 tek bir kavramda birleşiyor: Modüler Hesap Soyutlama Mimarisi Oluşturmak (Modüler AA).

Modüler AA, akıllı hesapları kullanıcılar için özelleştirmek üzere modüler hale getirmeyi ve geliştiricilerin özellikleri minimum kısıtlamayla sorunsuz bir şekilde geliştirmelerine olanak sağlamayı öngören daha geniş AA hareketi içindeki bir niştir.

Ancak herhangi bir sektörde yeni bir standart oluşturmak ve tanıtmak büyük bir zorluktur. Herkes asıl çözüme karar vermeden önce ilk aşamalarda birçok farklı çözüme tanık olunabilir. Ancak ister 4337 SDK olsun, ister cüzdan geliştiricileri, altyapı ekipleri veya protokol tasarımcıları olsun, hesap soyutlama üzerinde çalışanların hepsinin süreci hızlandırmak için bir araya geldiğini görmek cesaret verici.

Modüler Yapı: Ana Hesap ve Modüller

Hesap, işlevleri gerçekleştirmek için modülleri nasıl çağırır?

Delege görüşmesi ve vekalet sözleşmesi

Harici çağrı ve temsilci çağrısı:

DelegeCall hakkında

Temsilci çağrı çağrıya benzese de hedef sözleşmeyi kendi bağlamında yürütmek yerine, onu çağıran sözleşmenin mevcut durumu bağlamında 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 yapılacağı anlamına gelir.

Vekalet sözleşmesi ve temsilci çağrısı

Şekillendirilebilir ve yükseltilebilir yapıyı gerçekleştirmek için “Proxy sözleşmesi” adı verilen temel bir bilgiye ihtiyaç vardır.

1. Proxy sözleşmesi: Normal bir sözleşme, dağıtımdan sonra güncellenemeyen mantığını ve durumlarını saklar. Başka bir sözleşmeye temsilci çağrısı kullanan bir vekil sözleşme. Uygulama fonksiyonuna atıfta bulunarak onu vekalet sözleşmesinin mevcut durumunda yürütür.
2. Kullanım örnekleri: Proxy sözleşmesi değişmez kalsa da proxy'nin arkasında yeni bir uygulama 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üvenli Mimari

Güvenli Mimari

Güvenli Nedir:

Safe , savaşta test edilmiş güvenlik ve esneklik sağlamak üzere tasarlanmış lider bir Modüler Akıllı Hesap Altyapısıdır ve geliştiricilere çeşitli uygulamalar ve cüzdanlar oluşturma yetkisi verir. Pek çok ekibin Safe'in üzerine inşa ettiği veya ondan ilham aldığı dikkat çekicidir. Biconomy, Safe'i yerel 4337 ve 1/1 çoklu imzalarla genişleterek hesabını başlattı. 164.000'den fazla sözleşmenin dağıtımına ve 30,7 milyarı aşan değerin kilitlenmesine tanık olan Safe, şüphesiz uzaydaki öncüdür.

What's Safe'in yapısı

1. Güvenli hesap sözleşmesi: Ana vekalet sözleşmesi (Durum bilgisi olan)
   Güvenli hesap bir vekil sözleşmesidir çünkü delege çağrıları tekil bir sözleşmedir. Güvenli Hesap sahipleri içerir, eşik ve uygulama adreslerinin tümü proxy'nin değişkenleri olarak ayarlanır, dolayısıyla durumu tanımlanır.
2. Singleton sözleşmesi: Entegrasyon Merkezi (Durumsuz)
   Singleton, Güvenli hesaba hizmet eder ve Eklenti, Kanca, İşlev İşleyici ve İmza Doğrulayıcı gibi farklı entegrasyonları entegre eder ve tanımlar.
3. Modül sözleşmesi: Özel mantık ve özellikler:
   Modüller güçlüdür. Modüler bir tür olan eklentiler, ödeme akışları, kurtarma mekanizmaları ve oturum anahtarları gibi farklı özellikleri tanımlayabilir ve zincir dışı verileri getirerek web2 ile web3 arasında bir köprü görevi görebilir. Güvenlik görevlisi olarak Hook ve Function Handler gibi diğer modüller her türlü talimata yanıt verir.

Safe'i benimsediğimizde ne olur:

1. Yükseltilebilir Sözleşmeler:
   Yeni eklentiler tanıtıldığında yeni bir singleton dağıtmak gerekir. Kullanıcılar, kasalarını tercihleri ve gereksinimlerine uygun olarak istenen tekli sürüme yükseltme özerkliğine sahiptir.
2. Şekillendirilebilir ve Yeniden Kullanılabilir Modüller:
   Eklentilerin modüler yapısı, geliştiricilerin işlevleri bağımsız olarak oluşturmasına olanak tanır. Daha sonra bu eklentileri kullanım durumlarına göre özgürce seçip birleştirebilirler, böylece son derece özelleştirilebilir bir yaklaşım teşvik edilir.

ERC-2535 Elmas Vekiller

ERC2535 Elmas Mimarisi

ERC2535, Diamond Proxy'ler Hakkında:

ERC2535 , dağıtımdan sonra yükseltilebilen/genişletilebilen ve neredeyse hiçbir boyut sınırı olmayan modüler bir akıllı sözleşme sistemi olan elmasları standartlaştırır. Şimdiye kadar Zerodev'in Kernel'i ve Soul Wallet'ın deneyi gibi pek çok ekip bundan ilham aldı.

Elmas yapısı nedir:

1. Elmas sözleşme: Ana vekil sözleşme (Durum bilgisi olan) Elmas, delege çağrısını kullanarak uygulamalarından işlevleri çağıran bir vekil sözleşmedir.
2. Modül/Eklenti/Faset sözleşmesi: Özel mantık ve özellikler (Durumsuz) Bir Modül veya diğer adıyla Facet, özelliklerini bir veya daha fazla elmasa dağıtabilen durumsuz bir sözleşmedir. Bunlar dahili işlevleri, kitaplıkları ve durum değişkenlerini paylaşabilen ayrı, bağımsız sözleşmelerdir.

Diamond'ı sahiplendiğimizde ne olur:

1. Yükseltilebilir Sözleşmeler: Diamond, farklı eklentileri izole etmek ve bunları birbirine bağlamak ve aralarında veri paylaşmak için sistematik bir yol sağlar, ayrıca elmasCut işlevini kullanarak herhangi bir eklentiyi doğrudan ekler/değiştirir/kaldırır. Zamanla elmaslara eklenebilecek eklenti sayısında herhangi bir sınırlama yoktur.
2. Modüler ve yeniden kullanılabilir eklenti: Dağıtılmış bir eklenti, dağıtım maliyetlerini büyük ölçüde azaltmak için herhangi bir sayıda elmas tarafından kullanılabilir.

Güvenli Akıllı Hesap ile Elmas Yaklaşımı arasındaki fark:

Safe ve Diamond mimarileri arasında çok sayıda benzerlik vardır; her ikisi de özünde proxy sözleşmelerine dayanır ve yükseltilebilirlik ve modülerlik elde etmek için mantık sözleşmelerine referans verir.

Bununla birlikte, temel ayrım mantık sözleşmelerinin ele alınmasında yatmaktadır. İşte daha yakından bir bakış:

1. Esneklik:
   Yeni eklentilerin etkinleştirilmesi bağlamında Safe, değişikliğin Proxy'sinde uygulanması için Singleton sözleşmesinin yeniden dağıtılmasını gerektirir. Buna karşılık Diamond bunu doğrudan Proxy'sindeki elmas Kesim işlevi aracılığıyla başarır. Yaklaşımdaki bu farklılık, Safe'in daha yüksek düzeyde kontrole sahip olması anlamına gelirken, Diamond gelişmiş esneklik ve modülerlik sunar.
2. Güvenlik:
   Şimdilik her iki yapıda da kullanılan delege çağrısı, harici kodun ana sözleşmenin depolanmasını değiştirmesine izin verebilir. Safe mimarisinde, temsilci çağrısı tek bir mantıksal sözleşmeye işaret ederken Diamond, birden fazla modül sözleşmesi eklentisi genelinde temsilci çağrısını kullanır. Sonuç olarak, kötü amaçlı bir eklenti başka bir eklentinin üzerine yazma potansiyeline sahiptir ve bu da Proxy'nin bütünlüğünü tehlikeye atabilecek depolama çakışmaları riskini ortaya çıkarır.
3. Maliyet:
   Diamond yaklaşımının doğasında bulunan esneklik, artan güvenlik endişeleriyle el ele gidiyor. Bu, maliyet faktörünü artırır ve her yeni eklentinin eklenmesiyle kapsamlı denetimler yapılmasını gerektirir. Burada önemli olan, bu eklentilerin birbirlerinin işlevlerine müdahale etmemesini sağlamaktır; bu, özellikle sağlam güvenlik standartlarını korumaya çalışan küçük veya orta ölçekli işletmeler için zorluk teşkil eder.

“Güvenli Akıllı Hesap yaklaşımı” ve “Elmas Yaklaşımı” proxy ve modülleri içeren farklı yapılara örnek teşkil etmektedir. Esneklik ve güvenliğin nasıl dengeleneceği çok önemlidir ve bu iki yöntem gelecekte potansiyel olarak birbirini tamamlayabilir.

Modül Dizisi: Doğrulayıcı, Yürütücü ve Kanca

Modülleri çağırma sırası nedir?

Alchemy ekibi tarafından önerilen, Diamond'dan ilham alan ve ERC-4337 için özel olarak tasarlanmış bir standart olan ERC6900'ü tanıtarak tartışmamızı genişletelim. Ortak arayüzler sağlayarak akıllı hesaplardaki modülerlik sorununu çözer ve eklenti ile cüzdan geliştiricileri arasındaki çabaları 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 kanca. Bu adımların tümü, daha önce tartıştığımız gibi, modülleri çağırmak için proxy hesabı kullanılarak yönetilebilir. Farklı projeler farklı isimler kullansa da, temelde yatan benzer mantığı kavramak önemlidir.

Farklı tasarımdaki fonksiyon adları

1. Doğrulama: Arayanın hesaba kimlik doğrulamasını ve yetkisini sağlar.
2. Yürütme: Hesabın izin verdiği herhangi bir özel mantığı gerçekleştirir.
3. Hook: Başka bir fonksiyondan önce veya sonra çalışan bir modül görevi görür. Durumu değiştirebilir veya çağrının tamamının geri alınmasına neden olabilir.

ERC6900

Modülleri farklı bir mantığa göre ayırmak çok önemlidir. Standartlaştırılmış bir yaklaşım, akıllı sözleşme hesapları için doğrulama, yürütme ve kanca işlevlerinin nasıl yazılması gerektiğini belirlemelidir. İster Safe ister ERC6900 olsun, standardizasyon, belirli uygulamalara veya ekosistemlere özgü benzersiz geliştirme çabalarına olan ihtiyacın azaltılmasına yardımcı olur ve satıcıya bağlı kalmayı önler.

Modül Keşfi ve Güvenliği

Modülleri açık bir şekilde bulma ve doğrulama

Hız kazanan bir çözüm, kullanıcıların doğrulanabilir modülleri keşfetmesine olanak tanıyan, "kayıt defteri" diyebileceğimiz bir yerin oluşturulmasını içerir. Bu kayıt defteri, bir "Uygulama Mağazası"na benzer şekilde çalışır ve basitleştirilmiş ancak gelişen bir modüler pazar yerini teşvik etmeyi amaçlamaktadır.

Güvenli{Core} Protokolü

Güvenli{Core} Protokolü

Güvenli{Core} Protokolü, iyi tanımlanmış standartlar ve kurallar yoluyla sağlam güvenliği korurken çeşitli satıcılar ve geliştiriciler için erişilebilirliği artırmak üzere tasarlanmış, akıllı sözleşme hesaplarına yönelik açık kaynaklı, birlikte çalışabilen bir protokoldür.

1. Hesap: Güvenli{Core} Protokolünde hesap kavramı esnektir ve belirli bir uygulamaya bağlı değildir. Bu, çeşitli hesap hizmeti sağlayıcılarının katılımını sağlar.
2. Yönetici: Yönetici, Hesaplar, Kayıtlar ve Modüller arasında koordinatör olarak görev yapar. Ayrıca izin katmanı olarak güvenlikten de sorumludur.
3. Kayıtlar: Kayıtlar, güvenlik özelliklerini tanımlar ve Modüller için ERC6900 gibi standartları uygulayarak hem keşfedilebilirlik hem de güvenlik için açık bir "uygulama mağazası" ortamı oluşturmayı amaçlar.
4. Modüller: Modüller işlevleri yönetir ve Eklentiler, Kancalar, İmza Doğrulayıcılar ve İşlev İşleyicileri dahil olmak üzere çeşitli başlangıç türlerinde gelir. Bunlar, belirlenen standartları karşılamaları koşuluyla geliştiricilerin katkıda bulunmasına açıktır.

Yapay Elmas Tasarımı

Yapay Elmas Tasarımı

Süreç şu şekilde gelişiyor:

1. Şema Tanımı Oluşturma: Şema, doğrulama için gerekli olan önceden tanımlanmış bir veri yapısı görevi görür. İşletmeler tarafından kendi özel kullanım durumlarına uyacak şekilde özelleştirilebilir.
2. Şemaya Dayalı Modül Oluşturma: Akıllı sözleşmeler modüller halinde kaydedilir, bayt kodu alınır ve şema kimliği seçilir. Bu veriler daha sonra kayıt defterinde saklanır.
3. Bir Modül için Onayın Elde Edilmesi: Onaylayıcılar/denetleyiciler, şema bazında modüller için doğrulamalar sağlayabilirler. Bu doğrulamalar benzersiz bir tanımlayıcı (UID) ve zincirleme için diğer doğrulamalara referanslar içerebilir. Zincirler arasında yayılabilirler ve hedef zincirlerde belirli eşiklerin karşılanıp karşılanmadığını doğrulayabilirler.
4. Çözümleyicilerle Karmaşık Mantığı Uygulamak: İsteğe bağlı olarak şemada ayarlanan çözümleyiciler devreye girer. Modül oluşturma, doğrulama oluşturma ve iptal sırasında çağrılabilirler. Bu çözümleyiciler, geliştiricilerin doğrulama yapılarını korurken karmaşık ve çeşitli mantıkları birleştirmelerine olanak tanır.
5. Kullanıcı Dostu Sorgu Erişimi: Sorgular, kullanıcıların güvenlik bilgilerine ön uçtan erişmesi için bir araç sunar. Bu EIP'yi burada bulabilirsiniz.

Bu şema ilk aşamalarında olmasına rağmen, merkezi olmayan ve işbirliğine dayalı bir şekilde bir standart oluşturma potansiyeline sahiptir. Kayıtları, geliştiricilerin modüllerini kaydetmesine, denetçilerin güvenliklerini doğrulamasına ve cüzdanların entegre olmasına olanak tanır ve kullanıcıların modülleri zahmetsizce bulmasına ve onay bilgilerini doğrulamasına olanak tanır. Gelecekteki birkaç kullanım şunlar olabilir:

1. Onaylayıcılar: Safe gibi güvenilir kuruluşlar, şirket içi modüller için onaylayıcı olarak Rhinestone ile işbirliği yapabilir. Eş zamanlı olarak bağımsız tasdikçiler de katılabilirler.
2. Modül Geliştiricileri: Açık bir pazar şekillendiğinde, modül geliştiricileri potansiyel olarak kayıt defteri aracılığıyla çalışmalarından para kazanabilirler.
3. Kullanıcılar: Cüzdanlar veya dApp'ler gibi kullanıcı dostu arayüzler aracılığıyla etkileşime giren kullanıcılar, modül bilgilerini inceleyebilir ve çeşitli onaylayıcılara güven verebilir.

“Modül Kaydı” kavramı, eklenti ve modül geliştiricileri için para kazanma yollarını açar. Ayrıca bir “Modül Pazaryeri”nin önünü açabilir. Bazı yönler Safe'in ekibi tarafından denetlenebilirken diğerleri merkezi olmayan pazarlar olarak ortaya çıkabilir, herkes için katkılar ve şeffaf denetim kayıtları davet edilebilir. Bunu dahil ederek satıcıya bağımlı kalmayı önleyebilir ve daha geniş bir kitlenin ilgisini çekecek gelişmiş bir kullanıcı deneyimi ekleyerek EVM'nin genişletilmesini destekleyebiliriz.

Bu yaklaşımlar tek bir modülün güvenliğini garanti etse de akıllı sözleşme hesaplarının daha geniş güvenliği kusursuz değildir. Meşru modülleri ve bunların depolama çakışmaları olmadığına dair kanıtları birleştirmek zor olabilir; bu da bu tür kaygıların giderilmesinde cüzdan veya AA altyapısının öneminin altını çizer.

Düşünceleri kapatmak

Modüler bir akıllı sözleşme hesap yığını kullanılarak cüzdan sağlayıcıları ve dApp'ler, teknik bakımın karmaşıklığından kurtarılabilir. Bu arada, harici modül geliştiricileri de bireysel ihtiyaçlara göre özelleştirilmiş hizmetler sunma fırsatına sahip oluyor. Bununla birlikte, ele alınması gereken zorluklar arasında esneklik ve güvenlik arasında bir denge kurulması, modüler standartların ileriye taşınması ve kullanıcılara akıllı hesaplarını kolayca yükseltme ve değiştirme olanağı veren 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ını temsil ediyor. SCA'nın potansiyelini tam olarak gerçekleştirmek için, sağlam paketleyici altyapısı ve eşler arası bellek havuzu, daha uygun maliyetli ve uygulanabilir SCA imzalama mekanizması, zincirler arası SCA senkronizasyonu ve yönetimi gibi Katman 2 çözümlerinden ek protokol katmanı desteğine ihtiyaç vardır. ve kullanıcı dostu arayüzler geliştirin.

İleriye baktığımızda, katılımın yaygın olduğu ve ilgi çekici soruların ortaya çıktığı bir gelecek öngörüyoruz: SCA sipariş akışı yeterince kârlı hale geldiğinde, geleneksel Madenci Çıkarılabilir Değer (MEV) mekanizmaları paketleyiciler oluşturmak ve değer yakalamak için sahaya nasıl girecek? Altyapı olgunlaştığında, Hesap Soyutlamaları (AA) nasıl "amaca dayalı" işlemler için temel katman olarak hizmet edebilir? Bizi izlemeye devam edin; manzara her dakika gelişiyor.

Önemli parçalar

1. Güvenli teknik inceleme: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Yapay elmas belgesi: https://docs.rhinestone.wtf/
3. Biconomy belgesi: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Yasal Uyarı:

1. Bu makale [SevenX Ventures ]'den yeniden basılmıştır. Tüm telif hakları orijinal yazara [SevenX Ventures] aittir. Bu yeniden basıma itirazlarınız varsa lütfen Gate Learn ekibiyle iletişime geçin; onlar konuyu hemen halledeceklerdir.
2. Sorumluluk Reddi: Bu makalede ifade edilen görüş ve görüşler yalnızca yazara aittir ve herhangi bir yatırım tavsiyesi teşkil etmez.
3. Makalenin diğer dillere çevirileri Gate Learn ekibi tarafından yapılır. Aksi belirtilmedikçe tercüme edilen makalelerin kopyalanması, dağıtılması veya intihal edilmesi yasaktır.