İster boğa piyasası ister ayı piyasası olsun, Ethereum ekosistemi sürekli olarak inşa ediliyor ve kendi kendini optimize ediyor. Bunlardan Hesap Soyutlama (AA), son yıllarda önemli bir ilerleme kaydetti ve uygulamalar, altyapı, kullanıcılar ve geliştiriciler dahil olmak üzere Ethereum ekosisteminin tüm bölümlerine nüfuz etti. AA'nın geniş çapta benimsenmesinin bir bütün olarak blockchain kullanım eşiğini düşüreceğini ve web2 kullanıcı deneyimini web3 endüstrisine tanıtacağını öngörebiliriz.
Potansiyel olarak milyarlarca dolarlık AA pazarının fırsatını yakalamak için BlockPI, AA'yı altyapı hizmetlerine entegre etmeyi planlıyor. AA alanındaki entegrasyon ve yenilik sayesinde BlockPI, AA kullanıcılarına blockchain sözleşmeli cüzdan hesaplarıyla etkileşim kurmanın daha rahat ve verimli bir yolunu sağlamayı taahhüt ediyor ve bu sektörde lider olmayı umuyor.
Bu makalede BlockPI ekibi, AA'ya ilişkin anlayışlarını derinlemesine inceleyecek ve bir altyapı hizmet sağlayıcısının bakış açısından düşüncelerini paylaşacaktır.
EOA ve sözleşme cüzdanı
AA kavramı, EOA hesaplarının sınırlamalarından kaynaklanmaktadır. Bir EOA hesabı (harici sahip olunan hesap), Ethereum'da bir genel anahtarla (blok zinciri adresi) temsil edilen ve özel bir anahtarla erişilen bir kullanıcı hesabıdır. Ethereum ekosisteminin önemli bir bileşenidir ve kullanıcıların blok zincirinde para transfer etmesine veya akıllı sözleşmelerle etkileşime girmesine olanak tanır. Bununla birlikte, birçok insan için bir EOA kullanmak başlı başına zorlu bir görev olabilir. Ayrıca, mevcut EOA hesabının kullanımda hala kullanıcı deneyimini etkileyen bazı sakıncaları vardır.
Birincisi, gaz ücretleri konusu. Her işlem kullanıcıya Gaz ücreti olarak önemli miktarda ETH'ye mal olacaktır (25 Gwei'lik Gaz fiyatını örnek olarak alın, basit bir ETH transferi için Gaz ücreti yaklaşık 0,5 ABD dolarıdır ve sözleşme etkileşimi için daha pahalı olacaktır. veya Gaz fiyatı daha yüksek olduğunda). Bu, özellikle ciddi ağ tıkanıklığı dönemlerinde küçük işlemleri çok pahalı hale getirir. Ek olarak, Gas için ödeme yapmak için yalnızca ETH kullanılabilir, bu da kullanıcıların cüzdanlarında ETH bulundurmaları gerektiği anlamına gelir, bu da birçok kullanıcı için yüksek bir giriş engeli oluşturur.
İkinci olarak, kullanıcıların gerçekleştirmek istediği bazı karmaşık işlemler için EOA diğer akıllı sözleşmelere güvenmelidir. Örneğin, bir kullanıcı zamanlı bir periyodik transfer ayarlamak istiyorsa, kullanıcının bu işlemi gerçekleştirmek için bu işlevle ETH'yi bir akıllı sözleşmeye aktarması gerekir.
EOA ile ilgili üçüncü sorun, sabit imzalı şifreleme algoritmasıdır. Ethereum ağı, işlemlerin gerçekliğini ve güvenliğini sağlamak için secp256k1 adlı bir dijital imza algoritması kullanır. Bu algoritma sisteme kodlanmıştır ve kullanıcılar diğer şifreleme algoritmalarını kullanmayı seçemezler.
Yukarıdaki üç soruna ek olarak, EOA'nın genel anahtarı ile özel anahtarı arasındaki bağlayıcı ilişki de bir sorundur. Özel anahtar, kullanıcıların EOA'ya erişmesinin tek yoludur, özel anahtar kaybolursa geri alınmayacaktır. Bu aynı zamanda EOA'daki onunla ilişkili tüm varlıkların geri alınamaz olacağı anlamına gelir.
Aynı zamanda, EOA'nın belirli doğrusal görevleri yerine getirirken sınırlamaları da vardır. Örneğin, bir kullanıcı bir işlemde belirteçleri onaylamak (onaylamak), değiş tokuş etmek (takas) ve onaylamamak (onaylanmamış simge) isterse, verimsiz ve zaman alıcı olan üç ayrı işlemin gerçekleştirilmesi gerekir.
İyi haber şu ki, sözleşme cüzdanları yukarıdaki tüm sorunları çözebilir. Bir sözleşme cüzdanı, temel olarak, Ethereum'da bir kullanıcının cüzdanı olarak kullanılabilen AA'yı uygulayan belirli bir akıllı sözleşme hesabı türüdür. Ayrıca kullanıcılara fonları yönetmek için daha esnek ve kişiselleştirilmiş bir yol sağlayabilir. Ethereum akıllı sözleşmesi tarafından gerçekleştirilebilen mantık olduğu sürece, sözleşme cüzdanı karşılık gelen işlevleri gerçekleştirebilir ve sağlayabilir.
Spesifik olarak, birden fazla sözleşme cüzdanı işlemi, zincir üstü bir işlem olarak paketlenebilir ve bu işlemler, bu işlemin Gas maliyetini paylaşabilir. Üçüncü taraf Gas ücretini ödemeye razı olursa, sözleşme cüzdanını kullanan kullanıcılar için Gas ödemeye gerek yoktur. Sözleşme cüzdanları aynı anda birden fazla doğrusal görevi de tamamlayabilir. Ek olarak, sözleşme cüzdanı ayrıca özel imzaların şifreleme algoritmasını destekler ve cüzdan kurtarma vb.
Sözleşme cüzdanlarının avantajları tartışması devam ederken, Ethereum topluluğu aslında sözleşme cüzdanları hakkında uzun vadeli araştırmalar yürütmüştür. Birçok EIP, hesap soyutlamayla ilgili sorunları araştırmış olsa da, 2021 itibarıyla birleşik bir standart oluşturulmamıştır. Aşağıda birkaç temsili EIP bulunmaktadır.
EIP-86
İlk olarak 2017'de Vitalik Buterin tarafından önerildi. Bu şema, imza doğrulamasını "soyutlamak" ve kontrol etmeme ortak amacı ile bir dizi değişiklik uygular, böylece kullanıcıların keyfi imza/nonce kontrolü gerçekleştirebilen "hesap sözleşmeleri" oluşturmasına olanak tanır.
EIP-2938
2020'de sunuldu. Bu EIP'nin başlığı Hesap Soyutlamadır. AA kavramı bu EIP'de iyi tanımlanmıştır. Yeni bir işlem türü olan AA işlemini sunar. İşlem, giriş noktası adresi (EntryPoint adresi) tarafından başlatılır ve AA sözleşme cüzdanını çağırır. EIP-2938, birleşik bir özellik sağlar ve resmi olarak AA hesap soyutlamasını Ethereum mutabakatına dahil eder. Spesifik olarak, iki yeni işlem kodu, üç genel değişken ve Ethereum mutabakatına farklı bir yük yapısı getiriyor.
EIP-3074
2020'de sunuldu. Bu EIP, AUTH ve AUTHCALL olmak üzere iki EVM talimatı sunar. AUTH, ortam değişkenlerini ECDSA imzalama yetkisine göre ayarlar. AUTHCALL aramayı yetkili bir hesap olarak gönderir. Bu, akıllı sözleşmelerin EOA adına işlem göndermesine izin verir. Ancak bu yine de AA için mükemmel bir çözüm değil. Yetkilendirme işlemi sürecinde, EIP-3074'ün orijinal değerin iletimi konusunda belirli kısıtlamaları vardır. Ve kullanıcı EOA'ya erişimini kaybederse, varlıklarını geri almanın hâlâ bir yolu yoktur. Özel anahtar sızdırılırsa, kullanıcının tüm varlıkları yeni hesaba aktarması gerekir.
Yukarıdaki tekliflerin hiçbiri, mutabakat katmanındaki değişiklik ihtiyacı veya tekliflerin yeterince kapsamlı olmaması nedeniyle resmi olarak Ethereum protokolüne dahil edilmedi. Bu nedenle Ethereum topluluğu, fikir birliğini değiştirmeden AA'yı Ethereum protokolüne nasıl dahil edeceğini keşfetmeye devam etti ve sonunda EIP4337'yi önerdi.
ERC - 4337
EIP-4337 ilk olarak Eylül 2021'de önerildi ve Mart 2023'te ERC-4337 olarak onaylandı. Yazarları arasında Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson ve Tjaden Hess yer alıyor.
EIP-4337, temel Ethereum protokolünü değiştirmeden AA'yı tanıtacak yıkıcı bir tekliftir. EIP-4337 sonunda, geliştiricilerin kendi akıllı sözleşme cüzdanlarını uygulamak için kullanabilecekleri ERC-4337 standardı haline geldi. Aynı zamanda standart, "Bundlers" ve "UserOperation mempool" gibi bazı ek altyapılar da sunar. Bu şekilde, blockchain sisteminin üst katmanında benzer işlevlere sahip bir Ethereum mempool'unu fiilen çoğaltır. Kullanıcının gönderdiği artık tek bir işlem değil, bir UserOperation'dır. Bu UserOperations, tek bir işlemde paketlenebilir ve Ethereum'a gönderilebilir.
Aşağıda, bazı yararlı yorumlarla birlikte Ethereum'daki [resmi belgeler] ERC-4337'nin ayrıntılı bir teknik açıklaması yer almaktadır.
ERC-4337'nin temel rolleri ve tanımları
UserOperation—bir kullanıcı adına gönderilen bir işlemin yapısını açıklar. Karışıklığı önlemek için "işlem" olarak adlandırılmaz ve diğer UserOperation'larla birlikte bir Bundle olarak paketlenmek üzere Bundler'a gönderilir. Paket daha sonra zincir üzerinde tek bir işlem olarak gönderilir.
Gönderen—UserOperation'ı gönderen sözleşme hesabı. M-cüzdan sözleşmesi, IAccount arayüzünü yapılandırmak için ERC-4337 standardına uygun olmalıdır.
EntryPoint - UserOperations paketini yürüten küresel tek sözleşme. Paketleyiciler/Müşteriler beyaz listesi desteklenen Giriş Noktaları. Sözleşme, Infinitism ekibi tarafından dağıtılmak üzere denetlenir ve onaylanır ve tüm Kullanıcı İşlemlerini yürütmekten ve sözleşmeleri Wallet Factory, Aggregator ve Paymaster dahil olmak üzere diğer rollerle bağlamaktan sorumludur. Sözleşme, EVM uyumlu zincirde aynı adrestedir.
Bundler—Mempool'dan birden çok UserOperation'ı paketleyen ve EntryPoint.handleOps() işlemini (geçerli blok üretici düğümü) oluşturan düğüm. Bundler hizmeti, blockchain düğümlerinden bağımsız olarak çalışabilir ve paketlenmiş UserOperations'ı RPC aracılığıyla gönderebilir.
Toplayıcı — Toplu imzaları doğrulamak için hesapların güvendiği bir yardımcı sözleşme. Paketleyiciler/Müşteriler, desteklenen imza toplayıcıları beyaz listeye ekler. Toplayıcılar, IAggregator arayüzünü ERC-4337 standardına göre yapılandırmalıdır.
Paymaster—sizin adınıza Gaz ödeyebilen akıllı bir sözleşme. EntryPoint sözleşmesine yeterli miktarda ETH yatırırsa, akıllı sözleşmeyi gönderene UserOperation'ın Gas ücretini ödeyerek Gas soyutlamasını etkili bir şekilde uygulayabilir. Paymaster, Paymaster arayüzünü yapılandırmak için ERC-4337 standardına uymalıdır. Paymaster, Gönderici ile anlaşma yapabilir. Örneğin, Gönderici, Paymaster'a USDC öder ve Paymaster, gönderdiği UserOperations'ın Gazını ödemek için ETH kullanır. Aslında, Paymaster herhangi birini desteklemeyi seçebilir.
Jeton
, ERC-20 dahil
Jeton
diğer zincirler bile
Jeton
.
Cüzdan Fabrikası—ERC-4337 kullanıcıları için sözleşme cüzdanları oluşturabilen akıllı bir sözleşme. Wallet Factory'yi dağıtmak lisans gerektirmez. Bir zincir üstü akıllı sözleşme olarak, kodu halka açıktır ve herkes tarafından incelenebilir. Yaygın olarak kullanılan bir Cüzdan Fabrikası, profesyoneller tarafından tamamen denetlenmelidir.
Aşağıdaki diyagram, EntryPoint sözleşmesinin diğer aktörlerle nasıl etkileşime girdiğini açıklar.
Paketleyiciler, bir UserOperation'ı girdi olarak kabul eden EntryPoint sözleşmesinin handleOps işlevini çağırır.
handleOps, zincirdeki UserOperation'ı doğrulayacak, belirtilen akıllı sözleşme cüzdan adresi tarafından imzalanıp imzalanmadığını kontrol edecek ve cüzdanın Bundler'ı telafi etmek için yeterli Gas'a sahip olup olmadığını onaylayacaktır.
Doğrulama geçilirse, handleOps, UserOperation'ın çağrı verilerinde tanımlanan işlev ve giriş parametrelerine göre akıllı sözleşme cüzdanı işlevini yürütür.
Öte yandan, Bundler, handleOps işlevini tetiklemek için EOA'yı kullandığında, Gas ücreti tahakkuk edecektir. Akıllı sözleşme cüzdanı, Bundlers Gas ücretlerini kendi hesap bakiyesinden ödeyebilir veya Paymaster sözleşmesinden bunun için ödeme yapmasını isteyebilir. UserOperations, zincir dışı doğrulama adımını yeterli Gas olmadan geçemez, yani zincir üzerinde işlemi gerçekleştirmeden önce başarısız olur. Yeterli Gaz olsa bile, çalışma zamanı hataları ve yürütme sırasındaki diğer nedenlerle UserOperations yine de başarısız olabilir. Bir Kullanıcı İşlemi için, sözleşmenin ifasının başarılı olup olmadığına bakılmaksızın, EntryPoint sözleşmesi, Bundler'a handleOps işlevini tetikleyen Gas ücretini ödeyecektir.
ERC-4337 yürürlüğe girdikten sonra, kullanıcılar artık iki şekilde blockchain işlemlerini başlatabilir. Biri geleneksel yoldur, yani EOA doğrudan işlemi başlatır. Diğeri, Bundler aracılığıyla UserOperation'ı başlatmak için ERC-4337 standardını kullanmaktır ve ardından Bundler bunu diğer UserOperations ile paketler ve ağ zincirine gönderir. Aşağıdaki akış şeması, normal bir EOA gönderme işlemi ile bir ERC-4337 sözleşme cüzdanı gönderme UserOperation arasındaki farkı göstermektedir.
Yol asfaltlandı, ancak henüz çok fazla yaya yok
ERC-4337, kullanıcıların ve geliştiricilerin Ethereum üzerinde AA kullanması ve oluşturması için güçlü bir çerçeve sağlar. Bu çerçeve önemli bir ilerleme olmasına rağmen, hala ele alınması ve çözülmesi gereken bazı zorluklar ve belirsizlikler var.
AA'nın benimsenmesi henüz başlangıç aşamasındadır. Dune ERC-4337 analiz paneline [ERC-4337 Hesap Soyutlama] göre, zincirde yalnızca 65 binden fazla Kullanıcı İşlemi gerçekleştirildi ve bunların %90'ı Poligon'dan geldi. Bu nedenle, şu anda gerçekleştirilen Kullanıcı İşlemlerinin sayısı hala çok azdır, bunların çoğu geliştirici testleridir ve yalnızca küçük bir kısmı gerçek kullanıcılardan gelir. AA'yı entegre eden ürünlerin henüz başlangıç aşamasında olduğunu not ediyoruz. Şu anda, Bundlers'ın bir bütün olarak hala kayıp durumunda olduğunu ve mevcut kaybın yaklaşık 700 MATIC'ten fazla olduğunu gözlemleyebiliyoruz. Bunun başlıca nedeni Poligon'daki bazı Paketleyicilerin gereken gazı yanlış tahmin etmesi ve bunun sonucunda Giriş Noktası tarafından döndürülen Gazın sunulan Paket tarafından tüketilen gazdan daha az olmasına neden olur. Bu sorunun Bundler istemci düzeyinde çözülmesi gerekiyor.
Bunun ötesinde, ele alınması gereken birkaç sorun var. Böyle bir sorun, Paketleyicilerin işlem hatalarını nasıl ele aldığıdır.
Birden fazla UserOperation'ı bir arada paketledikten sonra Paketleyiciler önce işlemi simüle edecek, sözleşme yürütme hatası olup olmayacağını tespit edecek ve Gönderen veya Paymaster tarafından iade edilen Gas ücretinin ödenen Gas ücretinden yüksek olup olmadığını hesaplayacaktır.
Kârlıysa, Bundler bu UserOperations grubunu bir işlem olarak blok düğümüne gönderir. Bununla birlikte, işlemin başarısız olması ve Bundler'ın Gaz ücretini ödemesine, ancak Giriş Noktasından Gaz geri ödemesini almamasına neden olması yine de mümkündür. Örneğin, bir kullanıcı farklı Paketleyicilere eylemler gönderebilir. Kâr için yer varsa ve simülasyon başarılı olursa, Bundler'lar bunu zincire taahhüt eder. Bu durumda, aynı anda farklı Paketleyiciler tarafından blok düğümüne bir Kullanıcı İşlemi gönderilirse, yalnızca bir işlem başarılı olur, bu da, yalnızca bir Paketleyicinin Giriş Noktası tarafından iade edilen Gaz ücretini alacağı ve diğer tüm Paketleyicilerin vadesi dolmayacağı anlamına gelir. zincirlemek ve Gaz kaybetmek. Bazı kişiler bu davranışın kötü niyetli bir saldırı olarak değerlendirilmesi gerektiğini düşünüp, Bundler'ın Gönderen adresini yasaklayabileceğini ve bu adresten gelecek istekleri reddedebileceğini savunsa da, kullanıcılar istemeden bu eylemi gerçekleştirebileceği için bu makul bir çözüm değildir. . Bu sorunun kodda, belki de geliştirilmekte olan bir genel mempool ağı aracılığıyla düzgün bir şekilde ele alınması gerekir. Ayrıca, Bundler'lar, işlem başarılı bir şekilde gerçekleştirilse ve simülasyon sonuçları kar için yer olduğunu gösterse bile ani gaz dalgalanmaları nedeniyle zarar görebilir.
Diğer bir konu da AA'dan elde edilebilecek maksimum çıkarılabilir değerdir (MEV). Ethereum bağlamında MEV genellikle madencilerin veya diğer işlem işlemcilerinin bir bloktaki işlem sırasını manipüle ederek veya kendi işlemlerini bir bloğa ekleyerek çıkardıkları değeri ifade eder. MEV mantığının AA'ya da uygulanabileceği fark edilebilir. Bunun nedeni, AA'da Bundler'ların, MEV edinme olanağı sağlayan UserOps'u özgürce sipariş edebilmesidir. Ancak, Bundler'ın MEV'yi ayıklayıp çıkaramayacağı, yeterli UserOperation'ın birlikte paketlenip paketlenemeyeceğine bağlıdır. Artık AA pazarının tamamı henüz emekleme aşamasında, bu nedenle Bundler MEV de emekleme aşamasında sayılabilir. AA'nın MEV'sinin iki yönde gelişebileceği görülebilir: biri Flashbots, Ultra Sound ve BloXroute gibi katılımcıların katılımıyla Ethereum ana ağına benzer; diğer yön ise adil sıralamayı uygulamak için bir Bundler konsensüsü oluşturmaktır. İkincisi, AA'da MEV'leri çıkarma olasılığını tamamen ortadan kaldıracaktır.
gelecekteki geliştirme
genel bellek havuzu
AA ekosistemi hâlihazırda çalışır durumda olsa da, hâlâ yapılacak çok sayıda geliştirme çalışması var. AA ekosisteminin tamamına bakıldığında, şu anda en büyük eksik parça genel mempool. Skandha Bundler istemcisinin geliştiricileri olan Etherspot ekibi, şu anda genel mempool içeren bir p2p ağı geliştiriyor. Herkese açık mempool'lardan oluşan bir p2p ağının bu yılın Ağustos ayında piyasaya sürülmesi bekleniyor.
Paket algoritması
Yol boyunca, Ethereum Vakfı birkaç seçkin AA geliştirme ekibini finanse etti. Şimdiye kadar, birkaç Bundler istemcisi geliştirildi ve şu anda kullanılabilir durumdadır. Bunların arasında bazıları çok olgun. Candide (Python ile yazılmış Voltaire Bundler), Pimlico (Type ile yazılmış Alto Bundler), Etherspot (Type ile yazılmış Skandha Bundler), Stackup (Go ile yazılmış Stackup-Bundler), vb.
İşte paketleme stratejisi konusu geliyor. Şu anda az sayıda UserOperation nedeniyle Paketleyiciler, sabit zaman aralıkları veya her Pakette belirli sayıda UserOperation gibi basit paketleme mantığını benimseyebilirler. Bununla birlikte, UserOperations sayısı arttıkça, özellikle genel mempool'un tanıtılmasından sonra, UserOperations'ı seçme ve paketleme stratejisi daha karmaşık hale gelir. Nedeni basit: AA ekosisteminde blockchain mutabakat protokolüne benzer bir mekanizma yok ve Bundler grubu karanlık bir orman haline geldi.Her Bundler kendi çıkarlarına göre görevlere öncelik veriyor ve birbiriyle rekabet ediyor. Genel mempool'ların aksine, özel mempool'lar daha erken görünebilir. UserOperations'ı genel mempool'dan paketlemek karlı olmadığı için, UserOperations'ı özel mempool'da paketlemek yine de mümkündür. Bu durumda, Bundler paketleme sırasında diğer Bundler'larla daha rekabetçidir.
Ek olarak, halka açık mempool'un kademeli olarak yaygınlaşmasıyla, içindeki UserOperations, farklı Gas kar beklentileri ve zincir üstü yürütme karmaşıklığı gibi çeşitli özelliklere sahiptir. Paketleyiciler, ilgili paket stratejilerini oluşturmak için çeşitli UserOperations kombinasyonlarının karlılığını değerlendirmek için zincir dışı simülasyonlar yürütecektir. Daha fazla UserOperation'ı paketlemek daha yüksek kar elde etme potansiyeline sahiptir, ancak aynı zamanda doğrulama hatası riskini de artırır. Doğrulama geçilse bile zincirde yürütme hatası riski devam eder. Buna karşılık, daha az paketleme ile UserOperations bunun tam tersidir.
Paketleyicilerin, blok üreticilerinin bu işlemi gerçekleştirme önceliğini etkileyecek olan kendi işlem gazı parametrelerini ayarlaması gerekir. Farklı tahmini Gaz fiyatı ve Gaz oynaklığı koşulları altında Paketleyiciler farklı paketleme stratejilerine sahip olabilir. Aynı zamanda, bu doğrulama ve politika hesaplamaları için yerel donanım bilgi işlem kaynaklarının ve blockchain düğüm kaynaklarının maliyetini de dikkate almak gerekir. Ek olarak, Bundler'ların ayrıca kullanıcılar için iyi bir kullanıcı deneyimi sağlamaları ve UserOperations'ı gönderdikten sonra kullanıcıların aşırı gecikmelerle karşılaşmamalarını sağlamaları gerekir.
Bu zorlukların çözümleri hala belirsiz olsa da, AA endüstrisinin gelişmesi ve geliştiricilerin ortak çabalarının sonunda bu sorunları çözeceğini güvenle söyleyebiliriz. Bir altyapı oluşturucu olarak BlockPI, geliştirici olarak veya diğer geliştiriciler için AA dostu altyapı sağlayarak, AA endüstrisinin gelişiminde bir sorun çözücü rolü oynamayı umuyor.
*Altyapı AA'ya uyum sağlamalıdır
AA, kullanıcıların blok zincirini kullanırken daha yüksek bir serbestlik derecesine sahip olması için Gönderen, Paketleyiciler, Gaz ödeyenler, sözleşme cüzdanları ve İmzalayanlar dahil olmak üzere zincir içi işlemlerde yer alan çeşitli rolleri soyutlar. Aynı zamanda, altyapı sağlayıcıları bu hizmetleri piyasadaki kendi yargılarına göre bağımsız olarak dağıtabilir.
AA'nın geniş çapta benimsenmesine uyum sağlamak için altyapı sağlayıcılarının öncelikle en az iki temel hizmet sağlaması gerekir: Bundler hizmeti ve Paymaster hizmeti.
Bundler hizmetinde, iyi bir kullanıcı deneyimi sağlamak için altyapı sağlayıcının Bundlers ile birlikte özel mempool geliştirmesi gerekebilir. Özellikle altyapı sağlayıcılarının, Bundler hizmetlerinin istikrarını sağlamak için çeşitli Bundler istemcilerini entegre etmesi gerekir. Bu Bundler istemcileri şu anda kullanıcılara ERC-4337 çekirdek geliştirme grubu tarafından sağlanan çeşitli standart JSON RPC yöntemleri sağlamaktadır. Gelecekte daha fazla RPC yönteminin kullanıcılara sunulacağı öngörülebilir. Altyapı hizmet sağlayıcılarının bu süreç boyunca bu yöntemlere yönelik desteği zamanında güncellemeleri gerekir.
Ayrıca, Bundler API ile kaynak düğüm istemci RPC'si arasında optimizasyon yapmak önemlidir. Geçerli düğüm istemcisi, AA için optimize edilmemiştir. Bazı Bundler API yöntemleri, AA için sağlanan verilere karşı bir dizin gerektirir. Örneğin, geçerli istemci, hash ile UserOperation'ı aradığında, tüm bloklardaki EntryPoint sözleşme günlüklerini taraması gerekir. Veri dizini yoksa, bu tek isteğin donanım kaynak tüketimi oldukça büyük olacak ve isteğin geri dönüş süresi de çok uzun olacaktır.
Ayrıca, kullanıcılara Gazsız bir kullanıcı deneyimi ve çeşitlendirilmiş hizmetler sunmak için, altyapı sağlayıcılarının farklı Paymaster hizmetlerini entegre etmek için farklı Paymaster hizmet sağlayıcılarıyla işbirliği yapması gerekir. Aynı zamanda, pazar talebine göre, altyapı sağlayıcıları da mevcut Paymaster hizmetlerine dayalı daha uygun entegre çözümler tasarlayabilir. Toplu imzalar, cüzdan fabrikaları vb. gibi diğer hizmetler de altyapının gelecekteki gelişimi ve entegrasyonu için potansiyel yönlerdir.
Kısacası, AA'nın geniş ölçekli uygulamasına uyum sağlamak için altyapı sağlayıcılarının hizmetlerini sürekli iyileştirmesi ve genişletmesi gerekir. Bu, Bundler hizmetlerini optimize etmeyi, farklı Paymaster hizmet sağlayıcılarıyla işbirliği yapmayı, çeşitli API arayüzlerini entegre etmeyi ve diğer potansiyel hizmetleri geliştirmeyi içerir. AA endüstrisi gelişmeye devam ettikçe, bu çabalar daha verimli, güvenli ve kullanışlı bir blockchain deneyimi sağlamaya yardımcı olacaktır.
Şu anda, BlockPI yukarıdaki hedeflere ulaşmak için çok çalışıyor. Sadece bu da değil, topluluktaki neredeyse tüm Bundler müşterileri ve Paymaster hizmet sağlayıcıları ile iletişim kurduk ve en önemli geliştirme görevimiz olarak AA'yı BlockPI ağına entegre edeceğiz. Aynı zamanda, kullanıcı ihtiyaçlarını anlamak için AA cüzdan geliştiricileri ile derinlemesine iletişim kurduk. Bizimle iletişim kurmak ve işbirliği yapmak için tüm Bundler'ları, Paymaster'ları ve cüzdanları içtenlikle memnuniyetle karşılıyoruz.
BlockPI'nin amacı, AA ekosistemini toplulukla birlikte inşa etmek ve geliştirmek ve AA ekosisteminin ilerlemesini ve refahını desteklemek için mümkün olan her şeyi yapmaktır. Toplulukla işbirliği yaparak, bir endüstri lideri olarak tüm AA endüstrisine katkıda bulunacağımızı ve sonraki geliştirme sürecini destekleyeceğimizi umuyoruz, böylece Web2 kullanıcıları blok zinciri teknolojisini engeller olmadan deneyimleyebilir.
View Original
The content is for reference only, not a solicitation or offer. No investment, tax, or legal advice provided. See Disclaimer for more risks disclosure.
Altyapı, hesap soyutlama yoluyla milyarlarca kullanıcıyı nasıl destekliyor?
İster boğa piyasası ister ayı piyasası olsun, Ethereum ekosistemi sürekli olarak inşa ediliyor ve kendi kendini optimize ediyor. Bunlardan Hesap Soyutlama (AA), son yıllarda önemli bir ilerleme kaydetti ve uygulamalar, altyapı, kullanıcılar ve geliştiriciler dahil olmak üzere Ethereum ekosisteminin tüm bölümlerine nüfuz etti. AA'nın geniş çapta benimsenmesinin bir bütün olarak blockchain kullanım eşiğini düşüreceğini ve web2 kullanıcı deneyimini web3 endüstrisine tanıtacağını öngörebiliriz.
Potansiyel olarak milyarlarca dolarlık AA pazarının fırsatını yakalamak için BlockPI, AA'yı altyapı hizmetlerine entegre etmeyi planlıyor. AA alanındaki entegrasyon ve yenilik sayesinde BlockPI, AA kullanıcılarına blockchain sözleşmeli cüzdan hesaplarıyla etkileşim kurmanın daha rahat ve verimli bir yolunu sağlamayı taahhüt ediyor ve bu sektörde lider olmayı umuyor.
Bu makalede BlockPI ekibi, AA'ya ilişkin anlayışlarını derinlemesine inceleyecek ve bir altyapı hizmet sağlayıcısının bakış açısından düşüncelerini paylaşacaktır.
EOA ve sözleşme cüzdanı
AA kavramı, EOA hesaplarının sınırlamalarından kaynaklanmaktadır. Bir EOA hesabı (harici sahip olunan hesap), Ethereum'da bir genel anahtarla (blok zinciri adresi) temsil edilen ve özel bir anahtarla erişilen bir kullanıcı hesabıdır. Ethereum ekosisteminin önemli bir bileşenidir ve kullanıcıların blok zincirinde para transfer etmesine veya akıllı sözleşmelerle etkileşime girmesine olanak tanır. Bununla birlikte, birçok insan için bir EOA kullanmak başlı başına zorlu bir görev olabilir. Ayrıca, mevcut EOA hesabının kullanımda hala kullanıcı deneyimini etkileyen bazı sakıncaları vardır.
Birincisi, gaz ücretleri konusu. Her işlem kullanıcıya Gaz ücreti olarak önemli miktarda ETH'ye mal olacaktır (25 Gwei'lik Gaz fiyatını örnek olarak alın, basit bir ETH transferi için Gaz ücreti yaklaşık 0,5 ABD dolarıdır ve sözleşme etkileşimi için daha pahalı olacaktır. veya Gaz fiyatı daha yüksek olduğunda). Bu, özellikle ciddi ağ tıkanıklığı dönemlerinde küçük işlemleri çok pahalı hale getirir. Ek olarak, Gas için ödeme yapmak için yalnızca ETH kullanılabilir, bu da kullanıcıların cüzdanlarında ETH bulundurmaları gerektiği anlamına gelir, bu da birçok kullanıcı için yüksek bir giriş engeli oluşturur.
İkinci olarak, kullanıcıların gerçekleştirmek istediği bazı karmaşık işlemler için EOA diğer akıllı sözleşmelere güvenmelidir. Örneğin, bir kullanıcı zamanlı bir periyodik transfer ayarlamak istiyorsa, kullanıcının bu işlemi gerçekleştirmek için bu işlevle ETH'yi bir akıllı sözleşmeye aktarması gerekir.
EOA ile ilgili üçüncü sorun, sabit imzalı şifreleme algoritmasıdır. Ethereum ağı, işlemlerin gerçekliğini ve güvenliğini sağlamak için secp256k1 adlı bir dijital imza algoritması kullanır. Bu algoritma sisteme kodlanmıştır ve kullanıcılar diğer şifreleme algoritmalarını kullanmayı seçemezler.
Yukarıdaki üç soruna ek olarak, EOA'nın genel anahtarı ile özel anahtarı arasındaki bağlayıcı ilişki de bir sorundur. Özel anahtar, kullanıcıların EOA'ya erişmesinin tek yoludur, özel anahtar kaybolursa geri alınmayacaktır. Bu aynı zamanda EOA'daki onunla ilişkili tüm varlıkların geri alınamaz olacağı anlamına gelir.
Aynı zamanda, EOA'nın belirli doğrusal görevleri yerine getirirken sınırlamaları da vardır. Örneğin, bir kullanıcı bir işlemde belirteçleri onaylamak (onaylamak), değiş tokuş etmek (takas) ve onaylamamak (onaylanmamış simge) isterse, verimsiz ve zaman alıcı olan üç ayrı işlemin gerçekleştirilmesi gerekir.
İyi haber şu ki, sözleşme cüzdanları yukarıdaki tüm sorunları çözebilir. Bir sözleşme cüzdanı, temel olarak, Ethereum'da bir kullanıcının cüzdanı olarak kullanılabilen AA'yı uygulayan belirli bir akıllı sözleşme hesabı türüdür. Ayrıca kullanıcılara fonları yönetmek için daha esnek ve kişiselleştirilmiş bir yol sağlayabilir. Ethereum akıllı sözleşmesi tarafından gerçekleştirilebilen mantık olduğu sürece, sözleşme cüzdanı karşılık gelen işlevleri gerçekleştirebilir ve sağlayabilir.
Spesifik olarak, birden fazla sözleşme cüzdanı işlemi, zincir üstü bir işlem olarak paketlenebilir ve bu işlemler, bu işlemin Gas maliyetini paylaşabilir. Üçüncü taraf Gas ücretini ödemeye razı olursa, sözleşme cüzdanını kullanan kullanıcılar için Gas ödemeye gerek yoktur. Sözleşme cüzdanları aynı anda birden fazla doğrusal görevi de tamamlayabilir. Ek olarak, sözleşme cüzdanı ayrıca özel imzaların şifreleme algoritmasını destekler ve cüzdan kurtarma vb.
Sözleşme cüzdanlarının avantajları tartışması devam ederken, Ethereum topluluğu aslında sözleşme cüzdanları hakkında uzun vadeli araştırmalar yürütmüştür. Birçok EIP, hesap soyutlamayla ilgili sorunları araştırmış olsa da, 2021 itibarıyla birleşik bir standart oluşturulmamıştır. Aşağıda birkaç temsili EIP bulunmaktadır.
EIP-86
İlk olarak 2017'de Vitalik Buterin tarafından önerildi. Bu şema, imza doğrulamasını "soyutlamak" ve kontrol etmeme ortak amacı ile bir dizi değişiklik uygular, böylece kullanıcıların keyfi imza/nonce kontrolü gerçekleştirebilen "hesap sözleşmeleri" oluşturmasına olanak tanır.
EIP-2938
2020'de sunuldu. Bu EIP'nin başlığı Hesap Soyutlamadır. AA kavramı bu EIP'de iyi tanımlanmıştır. Yeni bir işlem türü olan AA işlemini sunar. İşlem, giriş noktası adresi (EntryPoint adresi) tarafından başlatılır ve AA sözleşme cüzdanını çağırır. EIP-2938, birleşik bir özellik sağlar ve resmi olarak AA hesap soyutlamasını Ethereum mutabakatına dahil eder. Spesifik olarak, iki yeni işlem kodu, üç genel değişken ve Ethereum mutabakatına farklı bir yük yapısı getiriyor.
EIP-3074
2020'de sunuldu. Bu EIP, AUTH ve AUTHCALL olmak üzere iki EVM talimatı sunar. AUTH, ortam değişkenlerini ECDSA imzalama yetkisine göre ayarlar. AUTHCALL aramayı yetkili bir hesap olarak gönderir. Bu, akıllı sözleşmelerin EOA adına işlem göndermesine izin verir. Ancak bu yine de AA için mükemmel bir çözüm değil. Yetkilendirme işlemi sürecinde, EIP-3074'ün orijinal değerin iletimi konusunda belirli kısıtlamaları vardır. Ve kullanıcı EOA'ya erişimini kaybederse, varlıklarını geri almanın hâlâ bir yolu yoktur. Özel anahtar sızdırılırsa, kullanıcının tüm varlıkları yeni hesaba aktarması gerekir.
Yukarıdaki tekliflerin hiçbiri, mutabakat katmanındaki değişiklik ihtiyacı veya tekliflerin yeterince kapsamlı olmaması nedeniyle resmi olarak Ethereum protokolüne dahil edilmedi. Bu nedenle Ethereum topluluğu, fikir birliğini değiştirmeden AA'yı Ethereum protokolüne nasıl dahil edeceğini keşfetmeye devam etti ve sonunda EIP4337'yi önerdi.
ERC - 4337
EIP-4337 ilk olarak Eylül 2021'de önerildi ve Mart 2023'te ERC-4337 olarak onaylandı. Yazarları arasında Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson ve Tjaden Hess yer alıyor.
EIP-4337, temel Ethereum protokolünü değiştirmeden AA'yı tanıtacak yıkıcı bir tekliftir. EIP-4337 sonunda, geliştiricilerin kendi akıllı sözleşme cüzdanlarını uygulamak için kullanabilecekleri ERC-4337 standardı haline geldi. Aynı zamanda standart, "Bundlers" ve "UserOperation mempool" gibi bazı ek altyapılar da sunar. Bu şekilde, blockchain sisteminin üst katmanında benzer işlevlere sahip bir Ethereum mempool'unu fiilen çoğaltır. Kullanıcının gönderdiği artık tek bir işlem değil, bir UserOperation'dır. Bu UserOperations, tek bir işlemde paketlenebilir ve Ethereum'a gönderilebilir.
Aşağıda, bazı yararlı yorumlarla birlikte Ethereum'daki [resmi belgeler] ERC-4337'nin ayrıntılı bir teknik açıklaması yer almaktadır.
ERC-4337'nin temel rolleri ve tanımları
UserOperation—bir kullanıcı adına gönderilen bir işlemin yapısını açıklar. Karışıklığı önlemek için "işlem" olarak adlandırılmaz ve diğer UserOperation'larla birlikte bir Bundle olarak paketlenmek üzere Bundler'a gönderilir. Paket daha sonra zincir üzerinde tek bir işlem olarak gönderilir.
Gönderen—UserOperation'ı gönderen sözleşme hesabı. M-cüzdan sözleşmesi, IAccount arayüzünü yapılandırmak için ERC-4337 standardına uygun olmalıdır.
EntryPoint - UserOperations paketini yürüten küresel tek sözleşme. Paketleyiciler/Müşteriler beyaz listesi desteklenen Giriş Noktaları. Sözleşme, Infinitism ekibi tarafından dağıtılmak üzere denetlenir ve onaylanır ve tüm Kullanıcı İşlemlerini yürütmekten ve sözleşmeleri Wallet Factory, Aggregator ve Paymaster dahil olmak üzere diğer rollerle bağlamaktan sorumludur. Sözleşme, EVM uyumlu zincirde aynı adrestedir.
Bundler—Mempool'dan birden çok UserOperation'ı paketleyen ve EntryPoint.handleOps() işlemini (geçerli blok üretici düğümü) oluşturan düğüm. Bundler hizmeti, blockchain düğümlerinden bağımsız olarak çalışabilir ve paketlenmiş UserOperations'ı RPC aracılığıyla gönderebilir.
Toplayıcı — Toplu imzaları doğrulamak için hesapların güvendiği bir yardımcı sözleşme. Paketleyiciler/Müşteriler, desteklenen imza toplayıcıları beyaz listeye ekler. Toplayıcılar, IAggregator arayüzünü ERC-4337 standardına göre yapılandırmalıdır.
Paymaster—sizin adınıza Gaz ödeyebilen akıllı bir sözleşme. EntryPoint sözleşmesine yeterli miktarda ETH yatırırsa, akıllı sözleşmeyi gönderene UserOperation'ın Gas ücretini ödeyerek Gas soyutlamasını etkili bir şekilde uygulayabilir. Paymaster, Paymaster arayüzünü yapılandırmak için ERC-4337 standardına uymalıdır. Paymaster, Gönderici ile anlaşma yapabilir. Örneğin, Gönderici, Paymaster'a USDC öder ve Paymaster, gönderdiği UserOperations'ın Gazını ödemek için ETH kullanır. Aslında, Paymaster herhangi birini desteklemeyi seçebilir.
Jeton
, ERC-20 dahil
Jeton
diğer zincirler bile
Jeton
.
Aşağıdaki diyagram, EntryPoint sözleşmesinin diğer aktörlerle nasıl etkileşime girdiğini açıklar.
Paketleyiciler, bir UserOperation'ı girdi olarak kabul eden EntryPoint sözleşmesinin handleOps işlevini çağırır.
handleOps, zincirdeki UserOperation'ı doğrulayacak, belirtilen akıllı sözleşme cüzdan adresi tarafından imzalanıp imzalanmadığını kontrol edecek ve cüzdanın Bundler'ı telafi etmek için yeterli Gas'a sahip olup olmadığını onaylayacaktır.
Doğrulama geçilirse, handleOps, UserOperation'ın çağrı verilerinde tanımlanan işlev ve giriş parametrelerine göre akıllı sözleşme cüzdanı işlevini yürütür.
Öte yandan, Bundler, handleOps işlevini tetiklemek için EOA'yı kullandığında, Gas ücreti tahakkuk edecektir. Akıllı sözleşme cüzdanı, Bundlers Gas ücretlerini kendi hesap bakiyesinden ödeyebilir veya Paymaster sözleşmesinden bunun için ödeme yapmasını isteyebilir. UserOperations, zincir dışı doğrulama adımını yeterli Gas olmadan geçemez, yani zincir üzerinde işlemi gerçekleştirmeden önce başarısız olur. Yeterli Gaz olsa bile, çalışma zamanı hataları ve yürütme sırasındaki diğer nedenlerle UserOperations yine de başarısız olabilir. Bir Kullanıcı İşlemi için, sözleşmenin ifasının başarılı olup olmadığına bakılmaksızın, EntryPoint sözleşmesi, Bundler'a handleOps işlevini tetikleyen Gas ücretini ödeyecektir.
ERC-4337 yürürlüğe girdikten sonra, kullanıcılar artık iki şekilde blockchain işlemlerini başlatabilir. Biri geleneksel yoldur, yani EOA doğrudan işlemi başlatır. Diğeri, Bundler aracılığıyla UserOperation'ı başlatmak için ERC-4337 standardını kullanmaktır ve ardından Bundler bunu diğer UserOperations ile paketler ve ağ zincirine gönderir. Aşağıdaki akış şeması, normal bir EOA gönderme işlemi ile bir ERC-4337 sözleşme cüzdanı gönderme UserOperation arasındaki farkı göstermektedir.
Yol asfaltlandı, ancak henüz çok fazla yaya yok
ERC-4337, kullanıcıların ve geliştiricilerin Ethereum üzerinde AA kullanması ve oluşturması için güçlü bir çerçeve sağlar. Bu çerçeve önemli bir ilerleme olmasına rağmen, hala ele alınması ve çözülmesi gereken bazı zorluklar ve belirsizlikler var.
AA'nın benimsenmesi henüz başlangıç aşamasındadır. Dune ERC-4337 analiz paneline [ERC-4337 Hesap Soyutlama] göre, zincirde yalnızca 65 binden fazla Kullanıcı İşlemi gerçekleştirildi ve bunların %90'ı Poligon'dan geldi. Bu nedenle, şu anda gerçekleştirilen Kullanıcı İşlemlerinin sayısı hala çok azdır, bunların çoğu geliştirici testleridir ve yalnızca küçük bir kısmı gerçek kullanıcılardan gelir. AA'yı entegre eden ürünlerin henüz başlangıç aşamasında olduğunu not ediyoruz. Şu anda, Bundlers'ın bir bütün olarak hala kayıp durumunda olduğunu ve mevcut kaybın yaklaşık 700 MATIC'ten fazla olduğunu gözlemleyebiliyoruz. Bunun başlıca nedeni Poligon'daki bazı Paketleyicilerin gereken gazı yanlış tahmin etmesi ve bunun sonucunda Giriş Noktası tarafından döndürülen Gazın sunulan Paket tarafından tüketilen gazdan daha az olmasına neden olur. Bu sorunun Bundler istemci düzeyinde çözülmesi gerekiyor.
Bunun ötesinde, ele alınması gereken birkaç sorun var. Böyle bir sorun, Paketleyicilerin işlem hatalarını nasıl ele aldığıdır.
Birden fazla UserOperation'ı bir arada paketledikten sonra Paketleyiciler önce işlemi simüle edecek, sözleşme yürütme hatası olup olmayacağını tespit edecek ve Gönderen veya Paymaster tarafından iade edilen Gas ücretinin ödenen Gas ücretinden yüksek olup olmadığını hesaplayacaktır.
Kârlıysa, Bundler bu UserOperations grubunu bir işlem olarak blok düğümüne gönderir. Bununla birlikte, işlemin başarısız olması ve Bundler'ın Gaz ücretini ödemesine, ancak Giriş Noktasından Gaz geri ödemesini almamasına neden olması yine de mümkündür. Örneğin, bir kullanıcı farklı Paketleyicilere eylemler gönderebilir. Kâr için yer varsa ve simülasyon başarılı olursa, Bundler'lar bunu zincire taahhüt eder. Bu durumda, aynı anda farklı Paketleyiciler tarafından blok düğümüne bir Kullanıcı İşlemi gönderilirse, yalnızca bir işlem başarılı olur, bu da, yalnızca bir Paketleyicinin Giriş Noktası tarafından iade edilen Gaz ücretini alacağı ve diğer tüm Paketleyicilerin vadesi dolmayacağı anlamına gelir. zincirlemek ve Gaz kaybetmek. Bazı kişiler bu davranışın kötü niyetli bir saldırı olarak değerlendirilmesi gerektiğini düşünüp, Bundler'ın Gönderen adresini yasaklayabileceğini ve bu adresten gelecek istekleri reddedebileceğini savunsa da, kullanıcılar istemeden bu eylemi gerçekleştirebileceği için bu makul bir çözüm değildir. . Bu sorunun kodda, belki de geliştirilmekte olan bir genel mempool ağı aracılığıyla düzgün bir şekilde ele alınması gerekir. Ayrıca, Bundler'lar, işlem başarılı bir şekilde gerçekleştirilse ve simülasyon sonuçları kar için yer olduğunu gösterse bile ani gaz dalgalanmaları nedeniyle zarar görebilir.
Diğer bir konu da AA'dan elde edilebilecek maksimum çıkarılabilir değerdir (MEV). Ethereum bağlamında MEV genellikle madencilerin veya diğer işlem işlemcilerinin bir bloktaki işlem sırasını manipüle ederek veya kendi işlemlerini bir bloğa ekleyerek çıkardıkları değeri ifade eder. MEV mantığının AA'ya da uygulanabileceği fark edilebilir. Bunun nedeni, AA'da Bundler'ların, MEV edinme olanağı sağlayan UserOps'u özgürce sipariş edebilmesidir. Ancak, Bundler'ın MEV'yi ayıklayıp çıkaramayacağı, yeterli UserOperation'ın birlikte paketlenip paketlenemeyeceğine bağlıdır. Artık AA pazarının tamamı henüz emekleme aşamasında, bu nedenle Bundler MEV de emekleme aşamasında sayılabilir. AA'nın MEV'sinin iki yönde gelişebileceği görülebilir: biri Flashbots, Ultra Sound ve BloXroute gibi katılımcıların katılımıyla Ethereum ana ağına benzer; diğer yön ise adil sıralamayı uygulamak için bir Bundler konsensüsü oluşturmaktır. İkincisi, AA'da MEV'leri çıkarma olasılığını tamamen ortadan kaldıracaktır.
gelecekteki geliştirme
genel bellek havuzu
AA ekosistemi hâlihazırda çalışır durumda olsa da, hâlâ yapılacak çok sayıda geliştirme çalışması var. AA ekosisteminin tamamına bakıldığında, şu anda en büyük eksik parça genel mempool. Skandha Bundler istemcisinin geliştiricileri olan Etherspot ekibi, şu anda genel mempool içeren bir p2p ağı geliştiriyor. Herkese açık mempool'lardan oluşan bir p2p ağının bu yılın Ağustos ayında piyasaya sürülmesi bekleniyor.
Paket algoritması
Yol boyunca, Ethereum Vakfı birkaç seçkin AA geliştirme ekibini finanse etti. Şimdiye kadar, birkaç Bundler istemcisi geliştirildi ve şu anda kullanılabilir durumdadır. Bunların arasında bazıları çok olgun. Candide (Python ile yazılmış Voltaire Bundler), Pimlico (Type ile yazılmış Alto Bundler), Etherspot (Type ile yazılmış Skandha Bundler), Stackup (Go ile yazılmış Stackup-Bundler), vb.
İşte paketleme stratejisi konusu geliyor. Şu anda az sayıda UserOperation nedeniyle Paketleyiciler, sabit zaman aralıkları veya her Pakette belirli sayıda UserOperation gibi basit paketleme mantığını benimseyebilirler. Bununla birlikte, UserOperations sayısı arttıkça, özellikle genel mempool'un tanıtılmasından sonra, UserOperations'ı seçme ve paketleme stratejisi daha karmaşık hale gelir. Nedeni basit: AA ekosisteminde blockchain mutabakat protokolüne benzer bir mekanizma yok ve Bundler grubu karanlık bir orman haline geldi.Her Bundler kendi çıkarlarına göre görevlere öncelik veriyor ve birbiriyle rekabet ediyor. Genel mempool'ların aksine, özel mempool'lar daha erken görünebilir. UserOperations'ı genel mempool'dan paketlemek karlı olmadığı için, UserOperations'ı özel mempool'da paketlemek yine de mümkündür. Bu durumda, Bundler paketleme sırasında diğer Bundler'larla daha rekabetçidir.
Ek olarak, halka açık mempool'un kademeli olarak yaygınlaşmasıyla, içindeki UserOperations, farklı Gas kar beklentileri ve zincir üstü yürütme karmaşıklığı gibi çeşitli özelliklere sahiptir. Paketleyiciler, ilgili paket stratejilerini oluşturmak için çeşitli UserOperations kombinasyonlarının karlılığını değerlendirmek için zincir dışı simülasyonlar yürütecektir. Daha fazla UserOperation'ı paketlemek daha yüksek kar elde etme potansiyeline sahiptir, ancak aynı zamanda doğrulama hatası riskini de artırır. Doğrulama geçilse bile zincirde yürütme hatası riski devam eder. Buna karşılık, daha az paketleme ile UserOperations bunun tam tersidir.
Paketleyicilerin, blok üreticilerinin bu işlemi gerçekleştirme önceliğini etkileyecek olan kendi işlem gazı parametrelerini ayarlaması gerekir. Farklı tahmini Gaz fiyatı ve Gaz oynaklığı koşulları altında Paketleyiciler farklı paketleme stratejilerine sahip olabilir. Aynı zamanda, bu doğrulama ve politika hesaplamaları için yerel donanım bilgi işlem kaynaklarının ve blockchain düğüm kaynaklarının maliyetini de dikkate almak gerekir. Ek olarak, Bundler'ların ayrıca kullanıcılar için iyi bir kullanıcı deneyimi sağlamaları ve UserOperations'ı gönderdikten sonra kullanıcıların aşırı gecikmelerle karşılaşmamalarını sağlamaları gerekir.
Bu zorlukların çözümleri hala belirsiz olsa da, AA endüstrisinin gelişmesi ve geliştiricilerin ortak çabalarının sonunda bu sorunları çözeceğini güvenle söyleyebiliriz. Bir altyapı oluşturucu olarak BlockPI, geliştirici olarak veya diğer geliştiriciler için AA dostu altyapı sağlayarak, AA endüstrisinin gelişiminde bir sorun çözücü rolü oynamayı umuyor.
*Altyapı AA'ya uyum sağlamalıdır
AA, kullanıcıların blok zincirini kullanırken daha yüksek bir serbestlik derecesine sahip olması için Gönderen, Paketleyiciler, Gaz ödeyenler, sözleşme cüzdanları ve İmzalayanlar dahil olmak üzere zincir içi işlemlerde yer alan çeşitli rolleri soyutlar. Aynı zamanda, altyapı sağlayıcıları bu hizmetleri piyasadaki kendi yargılarına göre bağımsız olarak dağıtabilir.
AA'nın geniş çapta benimsenmesine uyum sağlamak için altyapı sağlayıcılarının öncelikle en az iki temel hizmet sağlaması gerekir: Bundler hizmeti ve Paymaster hizmeti.
Bundler hizmetinde, iyi bir kullanıcı deneyimi sağlamak için altyapı sağlayıcının Bundlers ile birlikte özel mempool geliştirmesi gerekebilir. Özellikle altyapı sağlayıcılarının, Bundler hizmetlerinin istikrarını sağlamak için çeşitli Bundler istemcilerini entegre etmesi gerekir. Bu Bundler istemcileri şu anda kullanıcılara ERC-4337 çekirdek geliştirme grubu tarafından sağlanan çeşitli standart JSON RPC yöntemleri sağlamaktadır. Gelecekte daha fazla RPC yönteminin kullanıcılara sunulacağı öngörülebilir. Altyapı hizmet sağlayıcılarının bu süreç boyunca bu yöntemlere yönelik desteği zamanında güncellemeleri gerekir.
Ayrıca, Bundler API ile kaynak düğüm istemci RPC'si arasında optimizasyon yapmak önemlidir. Geçerli düğüm istemcisi, AA için optimize edilmemiştir. Bazı Bundler API yöntemleri, AA için sağlanan verilere karşı bir dizin gerektirir. Örneğin, geçerli istemci, hash ile UserOperation'ı aradığında, tüm bloklardaki EntryPoint sözleşme günlüklerini taraması gerekir. Veri dizini yoksa, bu tek isteğin donanım kaynak tüketimi oldukça büyük olacak ve isteğin geri dönüş süresi de çok uzun olacaktır.
Ayrıca, kullanıcılara Gazsız bir kullanıcı deneyimi ve çeşitlendirilmiş hizmetler sunmak için, altyapı sağlayıcılarının farklı Paymaster hizmetlerini entegre etmek için farklı Paymaster hizmet sağlayıcılarıyla işbirliği yapması gerekir. Aynı zamanda, pazar talebine göre, altyapı sağlayıcıları da mevcut Paymaster hizmetlerine dayalı daha uygun entegre çözümler tasarlayabilir. Toplu imzalar, cüzdan fabrikaları vb. gibi diğer hizmetler de altyapının gelecekteki gelişimi ve entegrasyonu için potansiyel yönlerdir.
Kısacası, AA'nın geniş ölçekli uygulamasına uyum sağlamak için altyapı sağlayıcılarının hizmetlerini sürekli iyileştirmesi ve genişletmesi gerekir. Bu, Bundler hizmetlerini optimize etmeyi, farklı Paymaster hizmet sağlayıcılarıyla işbirliği yapmayı, çeşitli API arayüzlerini entegre etmeyi ve diğer potansiyel hizmetleri geliştirmeyi içerir. AA endüstrisi gelişmeye devam ettikçe, bu çabalar daha verimli, güvenli ve kullanışlı bir blockchain deneyimi sağlamaya yardımcı olacaktır.
Şu anda, BlockPI yukarıdaki hedeflere ulaşmak için çok çalışıyor. Sadece bu da değil, topluluktaki neredeyse tüm Bundler müşterileri ve Paymaster hizmet sağlayıcıları ile iletişim kurduk ve en önemli geliştirme görevimiz olarak AA'yı BlockPI ağına entegre edeceğiz. Aynı zamanda, kullanıcı ihtiyaçlarını anlamak için AA cüzdan geliştiricileri ile derinlemesine iletişim kurduk. Bizimle iletişim kurmak ve işbirliği yapmak için tüm Bundler'ları, Paymaster'ları ve cüzdanları içtenlikle memnuniyetle karşılıyoruz.
BlockPI'nin amacı, AA ekosistemini toplulukla birlikte inşa etmek ve geliştirmek ve AA ekosisteminin ilerlemesini ve refahını desteklemek için mümkün olan her şeyi yapmaktır. Toplulukla işbirliği yaparak, bir endüstri lideri olarak tüm AA endüstrisine katkıda bulunacağımızı ve sonraki geliştirme sürecini destekleyeceğimizi umuyoruz, böylece Web2 kullanıcıları blok zinciri teknolojisini engeller olmadan deneyimleyebilir.